What Fedora makes sucking for me - or why I am NOT Fedora
Les Mikesell
lesmikesell at gmail.com
Wed Dec 10 18:27:52 UTC 2008
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
More information about the devel
mailing list