What Fedora makes sucking for me - or why I am NOT Fedora

[Les Mikesell]

Jesse Keating wrote:
> On Tue, 2008-12-09 at 18:22 -0600, Les Mikesell wrote:
>> One way or another, if I were building a distribution that wanted to 
>> simultaneously claim that it is both new code and 'tested and working', 
>> I'd try to plan in a way that it wasn't a flip of the coin on every 
>> machine which you'll get today.
> 
> Now here's a crazy idea, that nobody seems to want to follow:
> 
> Treat rawhide as your 'new code' land, leave the release trees as your
> 'testing and working' code.  That is don't be so goddamn eager to push
> new packages and new upstream releases to every freaking branch in
> existence.
> 
> Of course, when I make suggestions like these, I become extremely
> unpopular.

That might work if very large numbers of users used updates-testing.  Is 
that the case?  Without a large well-equipped (and paid?) QA team, and 
maybe even with, there are always going to be at least two types of 
problems that sneak by.  One is human error in deciding what to release 
and another is the kind of bug that only affects certain hardware or 
configurations that weren't tested.

Do you keep statistics on how many things fail to move from 
updates-testing to updates?   Maybe batching the moves would be enough 
to get the safety net effect.  What if updates-testing moved to updates 
once a month with a requirement that packages had spent at least 2 weeks 
in updates-testing or had been through a more stringent review to 
enforce extra safety checks on anything that had to be pushed (time 
values could be seasoned to taste), and an even more stringent policy 
would control emergency fixes directly to updates.   That way the people 
who want bleeding-edge would have to pull from updates-testing to get 
them (and the longer the cycle the more you would encourage this) and 
for machines where you have to avoid risks you could just not do updates 
   near the scheduled times for the moves, allowing a chance for 
emergency fixes to be pushed if needed.

--
   Les Mikesell
     lesmikesell at gmail.com