Re: Faster Release Cycle = More Up to date Packages...
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
> 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
Colin Watson [email@example.com]
To UNSUBSCRIBE, email to firstname.lastname@example.org
with a subject of "unsubscribe". Trouble? Contact email@example.com