Last September, some of the Debian Linux distribution's leadership wanted to make sure that Etch, the next version of Debian, arrived on its December 4th due date. Almost two months later, though, according to the February 17th Release Critical Bug Report memo to the Debian Developers Announcement list, there are still 541 release critical bugs.

You're missing my point -- which is that there's no rational way to prove that the disagreements concerning the Dunc-Tank project would have contributed to the delay of the Etch release. There are other technical reasons that explain the delay well enough. Don't ask me to look up information that either confirms or refutes this because such information just doesn't exist. This is the reason why I think that people should be careful not to spread these unproven allegations like they were actual facts.

As for the post written by those 17 developers who oppose Dunc-Tank -- yes, I've read it, but that post also lacks cold hard facts concerning the actual effects of their protest. AFAIK, there are more than a thousand Debian developers. Why should the opinions of 17 of them weight more than the opinion of the majority of the DD's? With such a large group of volunteers there are inevitably disagreements every now and then. It's not the end of the world, and it's certainly not the end of Debian. ;-)

Personally, I speculate that it's something much simpler. Linus had a really hard time delivering any kernel on time, no matter how hard he tried to enforce it. There were many excuses for the delay, including the "a release won't be finalized until it's stable" reason. But given that these days Linus *is* able to make regular stable releases that rarely slip, it's clear that those excuses were false. Things didn't start working smoothly with the Linux kernel until until the Linux development process changed the tools involved and changed the development and stabilization process. Something similar could be put in place for Debian.

Imagine if Debian unstable were "stabilized" once every month (or 2 weeks or 2 months, whatever works). If a package didn't make it in one month, no problem, wait 'til next release window (e.g. 1 month). This process would ensure that unstable never gets too broken and that people who want to rely on the bleeding edge, wouldn't have to worry about the spaces in between releases where packages are being stabilized (and thus might result in package breakage). Once every 6 months (or 9 months, again whatever works), an unstable release would be picked for further stabilization, and a beta stabilization release (aka testing) could be made every two months..

If some generally useful packages (e.g. GNOME or KDE or Apache or Linux kernel with Xen/KVM) missed the first "testing release" cut but got stabilized before the next unstable release, the Debian maintainers *may* decide to include in in the second testing release, but that's not guaranteed and if a package doesn't make it into the second testing release, it will have to wait until after the next stable release for inclusion. *No exceptions*.

After about a year of stabilization *without package updates only bug fixes*, nearly all the bugs should have been all worked out, so a stable release can be made.

At the end of that 1.5 to 2 year process, you will have a predictable, stable release, but it all comes down to project management.

Imagine if Debian unstable were "stabilized" once every month (or 2 weeks or 2 months, whatever works). If a package didn't make it in one month, no problem, wait 'til next release window (e.g. 1 month).

That would kill Debian for anything but casual use. The beauty of Debian stable is that you can do a apt-get update && apt-get upgrade and have the latest version of stable and secure packages. Now this comes down to one thing, configurations are NOT broken. Look at how the current stable would handle an upgrade to the latest clamav, it wouldn't. You have to manually fiddle the config files simply because overwriting and/or merging the new conf-files is a really shitty idea if you run more than a few servers.

Stable is stable for a reason, if you want the latest and greatest you run unstable or testing (etch).

Ubuntu is very nice but stuff breaks in far too many ways in between releases and that takes away some of the fun.

And yes, we run 100+ Debian servers at work, and my workstation is Ubuntu (which btw has piss-poor interactivity compared to my older and slower FreeBSD-Gnome laptop).