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 governments. 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 cold. 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. :) Regards, Mako -- Benjamin Mako Hill mako@canonical.com
Attachment:
signature.asc
Description: Digital signature