Jesse Keating wrote:
On Wed, 2008-11-19 at 10:03 +0200, shmuel siegel wrote:
I am not sure that you are right. The audience for updates tested might
very well be bigger than the one for updates testing. For example, I
always started using rawhide at test2, never at test1. Test1 was viewed
as pre-alpha and just too raw for someone who wanted a system that
basically worked but had some bugs.
I think you just described the problem again. The audience for "updates
tested" is going to be far larger than the audience for 'updates' or
'updates-testing', meaning that stuff isn't /really/ going to be tested
until it gets to that 'updates-tested' set of folks, which kind of
defeats the purpose.
That may or may not be true and it may or may not matter. All you need
is some large representative sample doing the early testing and a way to
ensure feedback to improve everyone's experience. And letting users
control their exposure to new bugs might increase the user base in both
categories. This choice should not be made and fixed at install time,
though. My experience with fedora is that for the first few months after
a release you want updates immediately since there are a lot of old
known bugs being fixed, but at some point there is a crossover where new
bugs are being introduced by the changes faster than the old ones are
fixed. Do you have any metrics regarding new bugzilla entries after
updates or updates that immediately replace a prior buggy update that
might quantify this impression or find an appropriate delay to have a
good chance of avoiding those quickly-replaced updates?
Also, when installing on new hardware you might want to have the very
latest updates until you are convinced that everything is stable, at
which point you will not be interested in any kernel or driver changes
which introduce risk for no benefit on that machine.
--
Les Mikesell
lesmikesell@xxxxxxxxx
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
