Is It Worth Installing F9 Alpha?

[Andrew Farris]

Michael Schwendt wrote:
> On Mon, 10 Mar 2008 04:08:32 -0700, Andrew Farris wrote:
> 
>>> 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.
> 
> qed.  Together with the cases where the post-Alpha packages get worse,
> that is a good example of why testing the Alpha doesn't make much sense.
> Even if a pkg in the Alpha worked fine, the next one may be one of the
> many infamous version upgrades that spreads wreckage all over the floor.
> The terminology (test1 -> test2, or alpha -> beta) doesn't matter much,
> if there is no road from the former release to the latter.
> 
> The recent F8 kernel update is in the same area. In bodhi it's at karma -6
> already, not counting anonymous users. The first tester there gave it +1
> although he had to delete/reconfig his network profiles (which probably
> was the same bug that hit me and killed the network).

And then noone else bothered during the entire week it was in updates-testing. 
A lack of manpower testing or just people too lazy to help provide feedback to 
the *community*-driven distro... Its not exactly hard to do on bodhi, so can 
making testing easier really be where the blame lies?  Hardly anyone took notice 
of that kernel until it hit updates, then all of a sudden there is feedback. 
Guess what?  That pretty much means people weren't actually testing.

>> F9 Development does however, need the testing, 
> 
> Then make it more tester-friendly.
> 
>> 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). 
> 
> Exactly that *is* a waste of resources.

Only in the case where the bug does not exist anymore.  Its not a waste if the 
bug still exists after the update (and alot of them do).

>> 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.
> 
> ... and open a new one, because the version upgrade (re-)introduces bugs.

You go back to the bug and reopen it, saying it still exists, and giving new 
feedback about any difference in its behavior.  Honestly, if you don't want to 
test software in a highly active development community then don't, I really do 
not see where you're going with this.  You would rather see less change occur in 
the development tree?  Or are you pushing for a more restricted and controlling 
policy on the packagers about when they can change major versions? (I would hope 
not to see this)

Things get developed and tested (and yeah they get re-broken) in rawhide much 
faster than the same new advancements happen elsewhere.  Thats a good thing. 
The breakage is a necessary by-product; you cannot change software quickly and 
only make changes that never break anything.  It just does not happen that way.

-- 
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
----                                                                       ----