Debian Core Consortium Releases First Code

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

Comments

Spoof mirror

[Anonymous Coward]

Screw the real site, the spoof is what's important: http://www.dccalliance.biz.nyud.net:8090/

link

[Anonymous Coward]

The story includes a link to the spoof website but not to the actual one. Great reporting.

The address is http://www.dccalliance.org/ btw.

Ubuntu

[Doros]

The real benefit of the alliance that I see is that .deb packages should be compatible across multiple distros. Unfortunately, Ubuntu is not part of the alliance, and there are a lot of 3rd-party Ubuntu .debs out there.

Re:Ubuntu

[Anonymous Coward]

The Debian release cycle has left many people unsatisfied. Some are working within the Debian Project to improve the release process. Some, such as Ubuntu, have elected to step outside of Debian to do short-term forks, while feeding changes back into Debian.

"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

[g2devi]

There are two reasons why Ubuntu is unlikely to join:

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

Re:Department of Redundancy Department?

[LiquidCoooled]

I believe the full Debian distribution and the DCC are 2 complimentary items.

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?

[digitalderbs]

The DCC seems like a good idea to me. From an earlier progeny news article, the DCC mandate is :

• Assemble a 100% Debian common core that addresses the needs of enterprise business users
• Maintain certification of the common core with the Free Standards Group open specification, the Linux Standard Base
• Use the Alliance's combined strength to accelerate the commercial adoption of Debian
• Work with the Debian project to ensure predictable release cycles and features important to commercial adoption

This seems very reasonable to me. There's something I'm missing -- Why the resistance and the spoof site?