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 215939
To view parent comment, click here.
To read all comments associated with this story, please click here.
Member since:

It's no secret that many Debian developers are upset about Dunc Tank. A Google search will make that clear. Further, I doubt anyone will admit to being one of the developers purposely delaying their work. Would you admit it? I doubt it. As for hard facts, they're scarce, but I did read this recently:

"A group of 17 developers, led by well-known Debian maintainer Joerg Jaspert, issued a position statement in October citing its disenchantment with Dunc-Tank. It read, "This whole affair already hurts Debian more than it can ever achieve. It already made a lot of people who have contributed a huge amount of time and work to Debian reduce their work. People left the project, others are orphaning packages...system administration and security work is reduced, and a lot of otherwise silent maintainers simply put off Debian work (to) work on something else."

Please stop acting like a litigator. I'm not wasting time providing names, addresses, dates and times so that my comments seems more credible to people like you. If you want more information, look it up yourself.

Reply Parent Score: 5

da_Chicken Member since:

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

Reply Parent Score: 4

g2devi 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