2008/3/10, Andrew Farris <lordmorgul@xxxxxxxxx>: > 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@xxxxxxxxx> 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@xxxxxxxxxx > 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 -- fedora-test-list mailing list fedora-test-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list
