On Thu, Apr 11, 2002 at 09:27:23PM -0400, Thomas Hood wrote: > Torsten Landschoff replied that "This was the whole idea of > testing. Experience shows it does not work." > > I think testing is an excellent thing to have, since it > provides a semi-stable proto-release. Unfortunately it is > true that the existence of testing hasn't shortened the > release cycle.
Largely, I think, because boot-floppies weren't ready in a plausible time, and we thought for a while that we'd be able to use debian-installer for woody. That all slowed things down. At the start we also had the move to package pools, and recently we had crypto-in-main which took a long time to get decided. The testing distribution also took a long time to settle down when it was first introduced. I remember spending a lot of time going through update_excuses.html and update_output.txt a year or so ago trying to work out where all the problems were. It seems to have mostly settled down to a steady state now where not too many nightmare package-renaming transitions are trying to happen at once, and it will start off the next release cycle in that state. *If* debian-installer is ready in time, then I think we have a good chance of being able to release woody+1 much more quickly than woody. If not, then I guess we don't. I'd like to see a team of QA people attacking release-critical bugs right from the start of the next release cycle, so that the rest of the distribution has a chance of staying releaseable. > But this argument fails for two reasons. Mr. Nielsen's > proposal is designed to speed up the release schedule, > not to increase the bug-fixing throughput. Instead of > doing 100 units of bug-breeding development followed by > 100 units of RC debugging, he suggests doing 50 units of > development, 50 units of RC debugging, 50 units of > development, 50 units of RC debugging. Of course it's > far from being so simple as that, but the overall idea > seems sound. It's not implausible - but everyone suggesting this kind of thing always forgets about the historical difficulty of getting the installation system ready. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]