[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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

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

Of course, when I make suggestions like these, I become extremely

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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]