Is It Worth Installing F9 Alpha?

Andrew Farris lordmorgul at gmail.com
Mon Mar 10 11:08:32 UTC 2008


Michael Schwendt wrote:
> On Mon, 10 Mar 2008 00:59:00 -0700, Andrew Farris wrote:
> 
>>> Meanwhile I need to fiddle with broken
>>> deps in the single repository which affect ordinary yum installs of
>>> package-chains needed for test-compiling software. Fine if the primary
>>> spin is free of broken deps, but the repository is broken.
>> yum --skip-broken, occasionally an --exclude=brokenstuff, and there should be no 
>> problem staying current unless
> 
> Both failed because a dependency-chain strictly required packages with
> broken deps.
>  
>>> One of the sporadic runs of "yum update" took more than three hours to
>>> update 700 pkgs. And one of the update pkgs killed X, which means it ends
>>> at a black screen when trying to start gdm or startx. It might be possible
>>> to "fix" it with a fresh xorg.conf. But why even try that? F9 development
>>> is a fast-moving target, known to be incomplete, known to be broken in
>>> several areas, with no signs of a base that justifies efforts of testing
>>> it.
>> Thats not very accurate.. there is plenty of justification for testing it -- 
>> there is just a different kind of testing needed.  Things are broken, *very* 
>> broken, so how can that not need testing? 
> 
> As in "we know... we hope to have it fixed next month or so".
> As in "this was probably fixed in rawhide, please update".
> As in "F9 Alpha ships foo 1.0, F9 Beta probably will ship foo 2.0 anyway".
> As in "yum update fubar, and it pulls in a huge chain of new deps from
> rawhide because of soname bumps etc".
> 
> Conclusively, after a few days already, the tester no longer tests F9 Alpha,
> but a rapidly changing collection of packages. Let's hope this will change
> with the Beta release and the feature freeze.

I was never really suggesting that 'Alpha' as a snapshot still needed testing. 
It is a well accepted fact that 'Alpha' is meant as a test of installability 
more than anything else and nearly all the packages are obsolete for testing 
purposes a week or two later.  F9 Development does however, need the testing, 
even now.  Especially now.  The more bugs that are found and fixed before the 
Beta, and in the week after it goes out.. the better.  Then people can get down 
to the usability testing.

>> There is good reason for an 
>> Alpha/Beta distinction,
> 
> Not if the changeset between the Alpha and the Beta release is too big
> or of uncertain quality. Because you cannot freeze together with the
> release of the Beta, which is a popular stage in the software release
> life cycle, if previous development was too wild and fragile.

Bugs fixed prior to the Beta do improve its state, but bugs are not generally 
fixed if the packager knows they are about to rebase to something completely 
different... the majority of that needs to happen before Alpha, and usually 
will.  That is the good reason for the distinction I'm talking about; any bugs 
in Beta really should matter, because the versions shouldn't be getting totally 
scrapped.  There is no need to directly compare a changeset from Alpha to Beta; 
the difference between them should be whether packages are all rebased to the 
intended final major versions.. (i.e. getting more stable).  Big sweeping 
changes between the two do not mean Beta is any less stabilized as what the 
release should be made up of.

Just because there is a new build of a package doesn't mean a report against a 
prior build is a waste of time either, it just means you have something to check 
in the future (whether it is fixed).  You report it, you check later after you 
update, if its still there then the developer knows about it early, if its not 
still there you close your own bug.  A moving target does not mean your testing 
is valid ONLY for a few minutes the morning of the repo build.  The vast 
majority of bugs exist across ALOT of package versions.

Someone testing rawhide should keep an eye on package versions they know they 
have open bugs in.. if it updates you check your bug that morning and make sure 
its still an open and valid bug.

-- 
Andrew Farris <lordmorgul at gmail.com> www.lordmorgul.net
  gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3
No one now has, and no one will ever again get, the big picture. - Daniel Geer
----                                                                       ----




More information about the test mailing list