F11 Proposal: Stabilization

[Les Mikesell]

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 at gmail.com