On Mon, Mar 21, 2005 at 11:13:40PM +0000, Matthew Garrett wrote: >... > People are far too busy picking on small details of proposals they don't > like instead of coming up with a decent and comprehensive set of > solutions. If you don't like what's been proposed, produce something > better. For the most part, that's how Debian works.
My proposal is: Change the release process to a release process without testing. Rationale: The whole release team plus Anthony Towns who's the main developer of testing signed the following statement: <-- snip --> We project that applying these rules for etch will reduce the set of candidate architectures from 11 to approximately 4 ([...]). This will drastically reduce the architecture coordination required in testing, giving us a more limber release process and (it is hoped) a much shorter release cycle on the order of 12-18 months. <-- snip --> If your release process has problems with the current number of architectures, you have two choices: - announce that you plan to drop two third of the architectures - change the release process I'd prefer the second choice. Testing has it's advantages. You know that all packages have there dependencies fulfilled [1], were built on all architectures, and some kinds of bugs are less likely to make it into testing. But testing also has it's costs (read e.g. what Steve listed as three points that "probably account for more of my release management time than anything else" [2] - they are testing specific tasks). Testing helps with some problems like ensuring that all dependencies are fulfilled and that packages have been built on all architectures - but this information is also available elsewhere. What instead? What about the simple pre-testing release process: - announce a freeze date - freeze unstable at the announced date - work a few months on improving frozen until it's in a releasable state I do believe that such a simple release process would allow releasing once a year with a dozen architectures. And if the buildd on an architecture wasn't able to keep up with unstable it wasn't nice - but it wasn't a problem for the release management since it was enough if the buildd started to keep up with frozen after the freeze (and the number of daily uploads to frozen should be much smaller than the number of daily uploads to frozen). This would therefore make (at least from a release management point of view) all discussions regarding the required speed of buildds obsolete. cu Adrian [1] but build dependencies are still not tracked [2] http://lists.debian.org/debian-devel/2005/03/msg02334.html -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
