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

Re: Ubuntu and CDDs

On Wed, Sep 29, 2004 at 01:54:01PM +0200, Miguel A. Arévalo wrote:
> El mar, 28-09-2004 a las 22:37 -0400, Benj. Mako Hill escribió:
> > 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.
> If "political" is having different objectives I agree, if that means
> "ideological" I don't agree.

Objectives and organizations, yes. :)

> > > 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.
> I think that the way of fixing this unpredictability is lobbying inside
> Debian to go for a time-based release cycle, not forking. And yes, I can
> create a GR to force it: If a package is not ready at a certain date it
> won't be on the Debian release. This will work out perfectly apart from
> base, but this is smaller and more predictable.
> For example d-i was not ready not only for sarge, but also for woody, if
> six months before the date marked for woody release they had recovered
> the boot-floppies woody would have been out it time.

IIRC, woody decided to go with boot-floppies *well* over 6 months
before the release. By that point, many of the people that were had
experience or expertise with boot floppies were interested in d-i and
not very excited about doing work on b-f.

You can reduce the time necessary for a release by limiting the size
of the problem (removing packages, settling for older code) but at the
end of the day there is work left to be done -- *a lot* of work in
most cases -- and I'm not optimisitic that passing decrees that
volunteers need to do x, y, and z is a good way to get anything
done. I know for a fact that for many people are active in important
places in Debian, the threat of this has the exact opposite effect.

> > Personally, I don't think Debian should ever release again. :) I
> > think
> Yes this would be very good news for Canonical, Ltd. :-D

That really wasn't my thinking and I'm not really quite sure it would
make a difference. If it makes any difference, I've been saying that
for *long* before anyone had even suggested Canonical or anything like
it. :)

You clipped the most important part. I suspect what we should see is
three of four major CDDs within Debian: lets say debian-server an
debian-desktop hyptothetically that almost everyone would use. Maybe
debian-gnome and debian-kde. Those groups would work on their RC bug
counts on their own, collaborate on an installer, and create their own
releases. Basically, I think it's unrealistic to make realeases of
15,000 packages and -- more importantly -- I think it's rather
unimportant. Lets release 1000 package CDDs and give users access to
those other packages in the grand Debian pool! :)
> > 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.
> I agree that no one should ever install anything but a CDD, but
> still based on Debian Stable.

I think that the idea of Debian stable as a homogenic entity should be
reconsidered. Every Debian should be a custom Debian! :)


Benjamin Mako Hill

Attachment: signature.asc
Description: Digital signature

Reply to: