Linked by Thom Holwerda on Fri 23rd Feb 2007 17:38 UTC, submitted by anonymous
Debian and its clones 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.
Thread beginning with comment 215968
To view parent comment, click here.
To read all comments associated with this story, please click here.
Member since:

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.

Reply Parent Score: 5

Chreo Member since:

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).

Edited 2007-02-24 13:38

Reply Parent Score: 1