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@xxxxxxxxx
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
