[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Ubuntu and CDDs

On Tue, Sep 28, 2004 at 11:49:17PM +0200, Miguel A. Arévalo wrote:
> El mar, 28-09-2004 a las 14:44 -0400, Benj. Mako Hill escribió:
> > On Tue, Sep 28, 2004 at 12:57:23PM +0200, Miguel A. Arévalo wrote:
> > > El mar, 28-09-2004 a las 11:50 +0200, Sergio Talens-Oliag escribió:
> > > > El Fri, Sep 24, 2004 at 09:35:40AM -0400, Benj. Mako Hill va escriure:
> > > 
> > > I also thought that, as I though with UserLinux and tried to bring
> > > them to the CDD camp but, as Ubuntu, they seem to like repeating
> > > previous errors.
> > 
> > What are those errors? Just the release cycle thing?
> The problems of making a fork (even sending back the patches and
> working to integrate them) instead of working out every problem
> inside of Debian.

What do you do when you have a fix or a low priority debconf that the
Debian maintainer says no to? What if they don't say no but they just
don't answer your emails? What if it's a very important package that
you can't NMU for what is, in the BTS, a minor or wishlist bug but
that is essential to your use? What you sometimes *must* do, from an
absolutist technical position, is forking and I don't think this needs
to automatically be a bad thing.

I think the fundamental difference between CDDs and projects like
Ubuntu is a political one. Which one has its homepage on
www.debian.org? Which one is bound by the technical committee's last
final word? I also think that's where the major difference should end.

My argument in that essay is this: Both CDDs and Ubuntu and UserLinux
and others are forking from an political and organizational
perspective. Lets not fixate on the political differences and find
ways and common tools to collaborate with each other!

> > I think this is close to accurate in my case but not the case for
> > everyone. I can't remember when I moved my machines away from testing
> > but a year and a half seems right. I hold on as long as I can but when
> > a year and half becomes two becomes three becomes more, even most of
> > the people you define as stable users feel the need to jump ship at
> > some point.
> In case of non-stable users (and that includes, for example, most
> home users) I think that a working testing (or releasable or
> whatever name is put on it) is more than enough.

Yes but non-stable users as you're defining them don't all agree that
this is more than enough. I suspect you telling them that it is enough
for them will not work either. :) These differences in opinion are
inevitable. The goal of CDDs should not be homogenize the expectations
of users but to create ways to both cater to everyone crazy little
desire and to do it in a way that shares with everyone else: all the
good things about forking without all the bad things!

> > Clearly, not everyone agrees with you. People like regular time-based
> > releases. People (especially companies) like *predictable* release
> > cycles. The fact Debian can't say when the next release will be is
> > worse than the fact that it might be 3+ years away in the eyes of many
> > people.
> > 
> 	Yes of course I agree, I do really like time-based releases,
> but I also like security support. And (like for example in Ubuntu)
> thinking about not having security support in a year after a
> deployment (and that in the most optimistic case) is a very bad
> thing. Is Canonical thinking on a Red Hat Enterprise like product ?

Canonical will guarantee 18 months of support, security and data loss
bugs for every stable release and will not charge for this. The
distribution and access to updates will always be free. There is no
plan for a pay-per-use or pay-for-support version of the distribution.

> > I don't think Debian-the-blob-with-15k-packages is particularly well
> > suited to provide either of these things. Politically independent, and
> > independently financed organizations can provide a good answer to both
> > of these. Internal projects that bring Debian to a manageable size
> > offer another technique.
> Well, I think that this is not that difficult, the only thing needed
> is the ability to say NO. And having a time-based release cycle
> makes receaving such NO is not that bad news. In fact Sarge is going
> to be released, in the end, as a result of a time-based decision.

Yes, but sarge is being released *years* after everyone expected and
had been told. Debian's release behavior makes it unsupportable and
unsuitable in the eyes of many users, vendors, companies, and

Having a small group of people tell Debian the organization how they
are going to change and when has never worked in the past. I think
it's better for Debian to focus on the things it does well, and there
are many, and to provide a framework so that people with different
organizational structures (either subprojects or external projects)
can do the things they do well in such a way that they collaborate.

> I think that if the developers working for companies on Debian
> should push for a time-based release cycle as a GR it would be
> aproved with great joy. Of course with a release cycle more in the
> like of Red Hat Enterprise than GNOME's or Ubuntu's 6 months.

I think this is wishful thinking. The release managers *wanted* a 1
year release cycle. It didn't happen. d-i wasn't ready, the social
contract changed and the release critical bugs were simply not
fixed. You can't create a GR to force Debian to go fix release
critical bugs buy a certain date! You can, but it won't work.

> > You don't have to agree with Ubuntu's idea of release-cycles to work
> > on ways to collaborate within the CDD infrastructure or otherwise. :)
> Yep, of course, and release-cycle discusion is out of the scope of this
> list ;-) , I think that in the end Debian will have a good solution on
> this.

I've been waiting for more than 7 years for that solution and have
even offered some of my own. Fact is, unless you have the time and
expertise to write or port installer or to single handedly fix
*hundreds* of release critical bugs, you're going to be out in the

Personally, I don't think Debian should ever release again. :) I think
we should create an infrastructure for the release of custom
distributions and only custom distribution! I think debian-server and
debian-desktop might be the big two and I think they should release
frequently but there could be tons of others ones. Debian should be
the big pool from which we all work.

> My point on Ubuntu (and Progeny and any other Debian-forked distros)
> is that working inside Debian is much more productive as a whole
> than forking the distribution. That's why I'm so interested on CDDs.

My entire point was that all derived distributions and all CDDs are,
from a purist technical level, forks and we need to drop the stigma
around this. The differences are political and organization. Once we
realize this, we can focus on the technology, the CDD framework in
this case with a larger group of people and we can decide where we can
and can't work together which. 

I don't care if there are 10,000 "forks" of Debian as long as they are
"forked" in such a way that they are working together. :)


Benjamin Mako Hill

Attachment: signature.asc
Description: Digital signature

Reply to: