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