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
