Is It Worth Installing F9 Alpha?

[Antonio M]

2008/3/10, Andrew Farris <lordmorgul at gmail.com>:
> 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
>  ----                                                                       ----
>
>  --
>
> fedora-test-list mailing list
>  fedora-test-list at redhat.com
>  To unsubscribe:
>  https://www.redhat.com/mailman/listinfo/fedora-test-list
>
I am running two F9 system in a mixed environment with F8 and Windows,
as a standard user and no software development (a normal clerical
office)

I find that at the moment the more disturbing bugs are in my
environment, others might have different bugs:
- no network resources tool working (it was working a week ago, not
100% but at least I could see shared resources)
- Firefox crashes when a PDF document is loaded
- keyboard bug (I am running F) in Italian..)

And on these particular bugs, I don't see much improvement.


-- 
Antonio Montagnani
Skype : antoniomontag