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! :) Regards, Mako -- Benjamin Mako Hill mako@debian.org http://mako.yukidoke.org/
Attachment:
signature.asc
Description: Digital signature