Debian Core Consortium Releases First Code 126
daria42 writes "It looks like the Debian Common Core Alliance announced a while ago is going to make good on its promises: the project has released its first code this week. The release consists of a base installation of Debian 3.1 with the Linux Standard Base and security updates attached. But the project also looks like it has attracted some criticism from within the Debian developer community - with a spoof Web site having already been set up to poke fun at the Alliance."
Spoof mirror (Score:5, Informative)
link (Score:5, Informative)
The address is http://www.dccalliance.org/ [dccalliance.org] btw.
Ubuntu (Score:1, Informative)
Re:Department of Redundancy Department? (Score:5, Informative)
From the DCC website:
What is the "DCC" of the DCC Alliance?
The DCC is not a Linux distribution; it is a "base" Debian system composed of essential programs or "packages" from Debian GNU/Linux, combined with member additions to attain LSB certification and achieve broad commercial acceptance and support.
It appears as thought this is the low level never changing set (just up from the kernel), and is similar to a bare Windows release, ie you have to add your own applications.
why the spoof site? (Score:5, Informative)
This seems very reasonable to me. There's something I'm missing -- Why the resistance and the spoof site?
Re:Ubuntu (Score:3, Informative)
"Release early, release often" is a good approach for software development. Large numbers of small, frequent changes can produce rapid improvement. Debian Experimental and Unstable show how well that approach can work.
But what's good for developers is horrible for users. Production systems need changes collected into larger, less frequent releases. That's what Debian Stable does. But it is very easy to get stuck in the 'collect' phase, and fail to make it to the 'release' part.
One solution to that problem is to schedule releases by date rather than feature set. The traditional, and Debian Stable, approach is to define what features will be in the next release, and release when the work is done. The result is that releases get pushed out by the slowest feature, and there is constant pressure to revise finished features, since they're waiting on the other guys anyway.
Schedule-based releases set release date targets, and work backwards from those. Features are prioritized, and only those features that can be incorporated by the release date are included. Features that fall below the cutoff can go into the following release.
I've seen two things happen with the time-based approach. One is that lower priority changes that didn't make the first release make it into the second release, and still beat the traditional model's first release date. The other is that feedback from the first release will show that some of the lower priority items slated for the second release need to be revised: some changed, some completely dropped.
Ubuntu is using the calendar-based release method for production releases, using Debian Unstable as their base. DCC is using Debian Stable as their base, and hoping to improve the Debian Stable release process. Different bases, different release strategies.
I'm sure that the current Debian Stable release process will improve. But I'm also sure that a much greater improvement will come with a switch to a calendar based approach. That won't happen without a working example to point to, such as Ubuntu. Debian is run by developers, and developers understand how to manage development releases, such as Unstable. But fewer developers understand how to manage production releases, and it shows. Debian needs to make a fundamental shift in how Stable releases happen. That shift will not happen without a working example of a better way. Such a shift happened with GCC, but only after a fork showed the way.
Re:Ubuntu (Score:2, Informative)
* Debian isn't even part of the DCC *commercial Debian* Alliance. Debian like Ubuntu aren't commercial distributions, so the DCCA isn't for them. If Debian were to join (or more likely, the DCCA join Debian), this barrier would disappear since Ubuntu tries to stay close to Debian SID as is stable.
* Ubuntu is based off of SID. DCC Alliance code is based off Sarge plus some selected backports. The only way Ubuntu could be based off of DCC Alliance code is if SID were backported to Sarge -- that sort of defeats the purpose of SID/Testing and seriously short-circuit the Debian process.