>> The only way it reduces the risk of releasing a botched update is >> the >> the updates somehow get more testing just by staying in the testing >> channel longer. > > ...and actual QA, from the professionals and volunteers on the QA team, > who are very good at finding bugs pre-release but currently do zero QA > on our updates because it's an unmanageable rolling stream of a > bazillion separate updates. With batched updates, you can test a batch > with the same overall criteria used for releases to see if it's > botched. That's the advantage of batching over simply extending the > amount of time spent in updates-testing. I've not seen that proposed anywhere, I'm not sure QA has the resources to actually do that. >> Which makes the question whether botched updates happen because not >> enough people use testing, or because there are enough people using >> it >> but they don't have enough time to spot the problems before the >> updates >> get pushed. > > We indeed do not need batched updates to extend the length of time > updates remain in testing. We could (and should) do that immediately. At the moment the time is a week, basically I don't see any real proposal to extend that overall, just to batch updates out on a Monday (not sure that is the best day if no one tests over a weekend). Most of the updates that go out quicker than a week are due to receiving the explicitly requested amount of karma. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx