On Wed, 2008-12-10 at 12:27 -0600, Les Mikesell wrote: > 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. If you're putting your potentially destabilizing feature adding version change into updates-testing, I've already lost my plea. Once in -testing, it's presumed that it, or something even newer, will be promoted to -updates, which ruins the whole thing. Seriously, if we could actually just focus on bugfixing for our released trees, do the new package work in rawhide (and bugfixing of the new packages there), our released trees might actually stabilize outside of the heavy handed forced freezes during development. It really really kills my motivation to make a release nice when a week after the release happens the giant piles of updates makes the whole thing more unstable than the pre-alpha. Releases just become speedbumps in the rawhide everywhere release mentality that seems pervasive in our packagers. I just get in the way of them doing whatever the hell they wan to do, and things like structured updates tools are just busy work and should be thrown out. Maybe I'm a bit cynical here. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
