Hi, Mark, I'm glad you took towards this list the effort of this message: On Wednesday 05 August 2009 11:21:38 Mark Shuttleworth wrote: > Hi folks > > I've stayed quiet in this discussion, though several folks have invoked > my name and ascribed motivations to me that were a little upsetting. I'm > not responding to that here, instead I'd like to focus on what we can > achieve together, and how we can lead a very significant improvement in > the health of the whole free software ecosystem. > > Apologies in advance if this mail is lengthy and not particularly witty!
The issue at hand it quite witty too, so I wouldn't take you for guilty (Wow! now I re-read my own message, it seems a perfect example on what NOT to do on the executive/project sponsor level -I hope, while I can't expect, you'll show the patient to read this to the end). > Imagine you are the leader of a key upstream component. You care about > your users, you want them to appreciate and love the software you write. > But you also know that most users won't get the code from you From my experience that's not usually the case. As already stated, it's more "you are not using last week's version, go figure for yourself". I already told my opinion (on a more "hatred" and witty way) here http://slashdot.org/comments.pl?sid=1318967&cid=28922369 so I won't repeat myself. > I hear this story all the time from upstreams. "We'd like to help > distributions, but WHICH distribution should we pick?" That's a very > difficult proposition for upstreams. They want to help, but they can't. > And they shouldn't have to pick favorites. The main point of my above URL is that basically most upstream projects do not plan in advance for long term maintenance (neither regarding their own code -that's basically why Debian is forced to backport instead of using the bugfixing branches from upstreamers) nor regarding their environment (while I can understand why they do it, it's still no good practice, maintenance-wise, using the bleeding-edge code from toolkits, libraries, etc. they depend upon). > Adopting a broad pattern of cadence and collaboration between many > distributions won't be a silver bullet for ALL of those problems, but it > will go a very long way to simplifying the life of both upstreams and > distribution maintainers. If upstream knows, for example, that MANY > distributions will be shipping a particular version of their code and > supporting it for several years (in fact, if they can sit down with > those distributions and make suggestions as to which version would be > best!) then they are more likely to be able to justify doing point > releases with security fixes for that version. I think your point is quite a sensible one and shows why you have been a successful entrepeneur (it shows "soft" abilities towards making things happening) but still I don't think that's something distributions need to be strongly looking after. If distributions A, B, C take version X, Y, Z from the upstream project "Foo" is mainly because such project doesn't provide clear notions on why X should have to be preferred over Y or Z. On the upstream projects that already do so, distributions do already take the published version that better fits their mood and intentions. For instance, disregarding end user misinterpretations, KDE is quite good and consistent -while not perfect, about their versioning policy and as a result of this, Debian decided not to rush for KDE 4 on lenny but still stay on the rock-solid KDE 3.5 while other, more edge-adicted distributions (like, say, Fedora) would start distributing KDE 4 and since the upstreamer properly does its homework it's all well and good. So, resuming: it's good for distributions that share some kind of "spirit" to somehow mildly try to converge on versions as a way to combine efforts and "show the path" to upstreamers while certainly it's still upstreamer's right and responsibility to do things properly -or not. > We're already seeing a growing trend towards cadence in free software, I don't think it's a free software property but that it's the proper way to go for these kinds of project (aided with proper dependency cascading and branching). The "problem" here is that the proper cadence for each project and even for a single project on different times it's their own so either the upstreamer does its homework the proper way or you won't be able to find the minimum common multiple you need to get stable and maintained versions for the thousands of packages that make up a distribution in a hundred year period (I speculated once on a "best practices for a project from distributions point of view" and the ability to declare some software projects as "blessed" and so preferred for a given task and managed on different, more efficient ways... but I'm disgressing) so, again, go with your "soft" abilities but don't worry about it too much (it's not on your hand, anyway). > OK, so that's the theory. How do we get there? How do we get many > distributions to sit down and explore the opportunities to agree on > common base versions for major releases? Easy: one at a time (and you already opened the "can of worms": probably a good thing). > Well, the first thing is to agree on the idea of a predictable cadence. Well, I can't be against this since that has been my opinion on what Debian should do for ages (provided some related problems regarding dependency cascading and branching are properly assesed). > Although the big threads on this list are a little heartbreaking for me > to watch, I'm glad that there hasn't been a lot of upset at the idea of > a cadence in Debian so much as *which* cadence. We can solve the latter, > we couldn't solve the former. So I'm happy at least at that :-) Well, I think the two years cycle has shown as a doable and acceptable consensus and it's probably perfect if it allows for some exceptions (like hardware compatibility and some volatile and/or end of dependency lines software, more or less what is currently managed by means of volatile and backports). The difficult point is not that but deciding if squeeze should be the first one or it would be better for the Debian's health to wait for squeeze+1 (note that while Debian Stable has a reputation for being rock solid, it's dismayingly too easy to break this confidence on just one shot -openssl anyone?). > > So, practically, we would be in a good position to collaborate. > > Psychologically, I don't know so much. > Have you ever noticed how family disputes can be the most bitter? While problably you are on spot with your analogy I don't think it really adds to the question at hand but a bit of poetry (not a bad thing, still). Disregarding all bitterness and harsh positions, Ubuntu is still more or less in the same position regarding Debian as it is Debian with regards upstream projects: Ubuntu can help to show the path, it can even put hands on it but it's still Debian's right and responsibility to do things its way; if others (like Ubuntu, but let's not forget other, even company-backed, efforts like Xandros or Mepis) find it useful for the own purpouses, good to know; if it fits so good that they commit efforts (money, hardware, developers...) even better, but Debian is Debian and Ubuntu|Xandros|Mepis... are different projects and on their own. I don't mean with this some kind of "superiority" on Debian that allows it to put its nose over the others, but that that's certain for these class of relationships and it's the healthy long-run way to go. > How do I think it could work in practice? Now: here is where the real meat starts [here some quite good selling speech that IMHO doesn't add so much but warming the audience for the next part] And now... > As I've said elsewhere, Ubuntu would be happy to reach a compromise if > needed to work with Debian and others. I think there's agreement on a > two year cadence, and if needed we can change one of our cycles to help > bring multiple distributions into line. Alternatively, with Debian > specifically, we can contribute resources to help Debian meet a stretch > (or squeeze ;-)) goal. Hear, hear!!! Since I thought from the beginning -and I think many with me, and that's probably the basis of the harsh opinion about Ubuntu of some individuals, that the "proper" way for Ubuntu should have been commiting the majority of hours directly on Debian instead of on Ubuntu (and I think that in the long run it's the best option for Canonical anyway), I can't think bad on this except, maybe, on the way you expect to put this in practice (which I foresee you plan on doing it through NMU patches instead of looking for ways to directly help those maintainers with problems/higher workloads). Not that I think you are "guilty" or something... again, I know you feel in a hurry (you run a company after all, and that costs money) and that when Ubuntu started (and even now) Debian has the "terrible defect" for a company that there's almost no way to build up on its brand recognition but you had to invent your own from zero. > From my perspective, committing Canonical > employees to help Debian freeze in December, or stretching our one cycle > to get us both onto a two year cadence, are roughly the same. It would > be unreasonable to expect us to do BOTH of those, but I'm happy to work > one either basis. Compromise requires some give from both parties, though. Good seller speech. But don't forget that compromise require for both parties wanting to reach such a compromise which probably is still not a settled issue (certainly -IMHO at least, the merits of Debian going for time-based releases holds by itself; matching those releases with anybody else's I see how it can benefit Ubuntu but still it's not clear how/if benefits Debian -real benefits, not theoretical or in a century might-bes) so... again in my opinion, it will have to be Canonical the one that puts more wood in the fire at least this time (and it will help to regain confidence for those Ubuntu haters or, at least, letting them without credible arguments). But... there's a third path I didn't see expressly stated: if (as it seems) a freeze in dec 2009 is too in a hurry for the Debian folks, maybe it can be done in two steps: freeze in feb/march 2010, publish about summer 2010 and then freeze squeeze+1 on december 2011 (that shouldn't have to be a problem if known so in advance) in order to go for the two year cycle from then on. I don't know if that means for Ubuntu to replan its calendar but I know that Canonical will still have to commit some resources (or at least counting for some form of resource buffering 'just-in-case') if it wants to insure those goals. Of course, for all I know from you (which, I must admit, is not that much) I bet you'll prefer the december-2009 sprint as your first choice, if only for the better "time to market" and the confidence it builds up seeing real things happening ASAP. > But most importantly, this whole thing will have it's best and biggest > impact if it goes beyond Ubuntu and Debian. Certainly yes. But at this given moment, it's still the "milkmaid's tale" (I think in English you use the expresion “to count your chickens before they have hatched”), so I'll won't go there now. > Third, I think we need to call on the people who are not fundamentally > prejudiced to speak out. Probably I not only talked but already talked a bit too much, so I'll stop here. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org