Re: On cadence and collaboration
Gunnar Wolf wrote: Of course, many upstreams will not accept this, as it breaks their workflow and might just feel outside influence from people they don't care too much about (and I'm not meaning the Linux desktops, as they obviously care about Linux distributions, but mainly OS-agnostic projects). Still, I think it would be worth a try. This is a good point. We do already see lots of upstreams moving to a cadence, which is improving their release energy and practices. There is *some* alignment between various upstreams, but at this stage it will take getting two or more distributions together in order to create a real center of gravity. Mark
Re: On cadence and collaboration
Cyril Brulebois wrote: Raphael Geissert geiss...@debian.org (05/08/2009): Like some people said during Debconf: freezing in December doesn't necessarily mean freezing the first day or even the first week of December; the 31 is still December, which means there are 30 days to decide many things, if necessary. Without having to resort to nitpicking on days, was the “freeze” term define anywhere? My main question would be: will it be possible to e.g. switch the default compiler right before the freeze and trigger possible hundreds of serious FTBFS bugs? Or is some incremental freeze still supposed to happen? (Putting -release in Cc to catch their attention.) At least on the Ubuntu side, there would be room to agree in advance on items that are as yet unreleased, but which have for various reasons clear advantages and well understood risks. So, for example, if someone on the toolchain team said GCC 4.5 is going to be released in February, and we've run a test rebuild of the archive and there were only 20 FTBFS's then it might well be possible to get consensus around that new version being planned as a consensus base version for releases in 2010. Mark -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: On cadence and collaboration
Julien BLACHE wrote: [Cc:ed as I don't know whether you're subscribed to -project] I am subscribed, yes, but thanks for the cc. From the very start of the Debian Project, Debian has been different from everything else: different package management tools, different philosophy, different organization, you name it. Debian stands out in many respects, yes. But being different for the sake of it isn't a laudable goal: if there's a good idea, it deserves to be considered, even if others are already considering it. Overall, it's been working fine for the last 16 years. A lot has been achieved, yes. Could more be done? Could Debian be stronger? Are there weaknesses that may be addressed? I think it's always worth considering how things can be improved. What do you think the changes you are proposing can gain us? I don't believe in the upstreams will care stuff (there are good examples of upstreams not giving a damn about distributors over the past months) and I don't believe in the 100% end-user-centric focus you're displaying in your mail. Well, we believe differently, and that's OK. I think it's easy enough to go and speak to a few upstreams, and ask them this: what would you do differently if you knew that multiple distributions would all sit down and think about which version of your code to ship with their big 2010 release? I think you'd find most of them say that would be amazing. Once I've removed that from your mail, and the but Ubuntu loves you! stuff, there's nothing left. Mark
Re: On cadence and collaboration
Julien BLACHE wrote: Debian stands out in many respects, yes. But being different for the sake of it isn't a laudable goal: if there's a good idea, it deserves to be considered, even if others are already considering it. Being different and independent actually enables us to be better at what we're doing than anyone else. I agree, that conscious, planned and considered differences are the best way to beat the competition or stand for your brand. If you do the same thing as everyone else it's very difficult to be better. But it is wise to think carefully about the things that one really wants to do differently. In business it makes sense to standardise on as much as possible, then be different on the key things that really do define you vs your competition. In Debian's case, I can think of several things that really define the brand and the values. Supporting more architectures. Having the most democratic processes. debian-legal. And many more. None of them depend on having the same, or different base versions of the major components as any other distro. There's a great expression that says if you always do what you always did, you can only expect to get again what you got before. In other words, it's always worth thinking about what can be done differently. If we were tied to something or someone one way or another, this would not be possible. Having a cadence and discussion across many distros to try and find opportunities for common base versions of major components does not tie anybody. If Debian wants to have a different version of ANY component to any other distro, of course it can! And if it wants to take 9 months to bake the release, instead of 6 months, of course it can too. There are real differences in approach (architectures etc) that will always drive some delta. It's worth paying the cost of that delta if it helps you be you. It's not worth having a delta just because nobody bothered to sit down and talk about it. Overall, it's been working fine for the last 16 years. A lot has been achieved, yes. Could more be done? Could Debian be stronger? Are there weaknesses that may be addressed? I think it's always worth considering how things can be improved. Indeed. And I truly don't see how being tied to and restricted by other projects with differing interests can help us there. Quite to the contrary. This proposal does not tie Debian in any way. Well, we believe differently, and that's OK. I think it's easy enough to go and speak to a few upstreams, and ask them this: what would you do differently if you knew that multiple distributions would all sit down and think about which version of your code to ship with their big 2010 release? I think you'd find most of them say that would be amazing. I don't really care about what they say, I care about how they act upon it afterwards. And unfortunately there's no guarantee that they'll support us better than they do today. Especially if those statements were made without community backing. There's no guarantee, no. But community members rally to a good, inspiring, intellectually true vision. You may not get them all, and you may not get the leader, but you will ensure that on every mailing list *someone* will be asking the question what can we do to help those guys with their noble cause? Mark
Re: On cadence and collaboration
Hi Marc Marc Haber wrote: this is kind of a personal reply; I am therefore writing this to you directly and only Cc'ing debian-project, and I do not know whether you read that mailing list. On Wed, Aug 05, 2009 at 10:21:38AM +0100, Mark Shuttleworth wrote: 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, A pity. I bet many people would like to hear that response. I've tried to clarify my motivations without responding to personal attacks. I hear this story all the time from upstreams. We'd like to help distributions, but WHICH distribution should we pick? I have never heard that story from an upstream, neither have I heard that other maintainers have heard that. Especially not from the upstream who consider themselves big and powerful. At the last Linux Collaboration Summit, a panel of kernel leaders said exactly this. We see more and more upstreams adopting time-based releases, and cadences of 3 or 6 months. A few are starting to think about 2-year long-term releases, too. So it fits. 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. It will also cost the free software ecosystem a lot of what's one of its most major properties: diversity. Diversity in distributions comes from choice of components, not from choice of component versions. Version skew just makes it much harder to collaborate. 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... which in turn makes it easier for the security teams and maintainers in the distribution. In practice, most upstreams adopt a you're using a version that's two weeks old, go update to our current development snapshot and see yourself whether the bug is still there attitude. That's true. To upstream there is tip (which all real developers run, right? ;-)) and then there's the cloud of released versions which distributions are still shipping. It's hard to get their attention about the particular version that any one distribution is shipping, but I think it's reasonable to believe it would be easier to get their attention about a version that *many* distributions adopted. Well, the first thing is to agree on the idea of a predictable cadence. 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 :-) Most upset that happened on the lists and in real life was about that Debian learned about your collaboration from a Debian press release. I agree, that was unfortunate. As pointed out on this list, Debian and Ubuntu share a great deal. I wouldn't call that share. We share many things, in the sense of having many things in common. Do you believe that this is an unfair, or unbalanced relationship? What does Ubuntu take from you, beyond that which you have freely given? And whatever Ubuntu brings back to Debian, is that not of value? We have largely common package names (imagine what a difference that will make to practical discussions over IRC ;-)) Right, this makes it much easier for Ubuntu users to pester Debian people with the problems that the Ubuntu community wasn't able to solve by itself. Noted. (most of the strongest Ubuntu contributors are or have been very strong Debian contributors too, yes, and have usually stopped doing their debian duties without properly stepping down upon their engagement with Ubuntu. This has greatly harmed Debian a few years ago when Ubuntu was still hatching, and has obviously also helped Ubuntu in getting more momentum than Debian since Ubuntu took privileges from Debian which slowed down Debian a great deal. The people concerned, for whom I have a great deal of respect, don't agree. and many new Debian maintainers have come to the project through Ubuntu) Yes. Ubuntu should think about the reason for Ubuntu people changing over to Debian. We see this differently. When a person comes to free software as an Ubuntu user, starts contributing to Ubuntu, then begins the process of becoming a Debian maintainer, and succeeds at it, I celebrate a win for free software. It helps greatly with the relationship and with general
Re: Debian decides to adopt time-based release freezes
Werner Baumann wrote: The two models as I can see them from the discussion so far: Model 1: Debian freezes in December Debian developers concentrate on fixing RC bugs Ubuntu developers concentrate on including newer versions of major software packages When the number of RC bugs in Debian is low enough Ubuntu freezes Ubuntu and Debian release at approximately the same time With this model Debian developers will bear the main burden of bug fixing while Ubuntu will use the time to integrate newer software packages. Model 2: Debian and Ubuntu freeze at the same time (December?) Debian and Ubuntu developers coordinate in fixing RC bugs Debian and Ubuntu release at about the same time With this model the burden is shared and both operating system will be at the same state with respect to the main components. Differences will be according to different philosophy (questions asked by the installer, components and configuration of a standard installation, what is user friendly). There may be also differences in the versions of main software packages, but this differences would be clear at freeze time and due to different philosophy. While I think model 2 could prove useful for Debian and Ubuntu I can't see what Debian would gain from model 1. I believe this discussion would look very different if Ubuntu says it agrees on model 2. We certainly agree on the idea that multiple distributions, and all the major upstreams, would benefit from a coordinated freeze. If we sit down and agree to use the same version of the kernel, for example, that helps the kernel community plan their merge windows and merge criteria in a way that they have never been able to do before. It would be substantially easier to collaborate on RC (and non-RC) bug fixes where the base versions of major components were the same. That said, I don't believe that any distribution should feel compelled to go with a particular version. If Mandriva really wants to go with a different version of X, say, then all power to them. There will be benefits to being on a common base with others, and there will sometimes be benefits or constraints which mandate a delta for any particular distribution. So, coordinated *freezes* make a lot of sense for distributions *and* for upstreams. However, when it comes to the release, there are equally good reasons for different distributions to take different approaches. We each have different policies and focuses. We treat different issues as release blockers. We are focused on different use cases. All of those will drive differences in release dates. So, I strongly support your Option 2 as the model, but I don't think it leads to exactly the same freeze-and-release dates. It leads to a shared freeze date where we establish how much common signalling we can send to upstreams, followed by improved collaboration both with other distributions and with upstreams, and varying release dates. Is that a bad thing? Well, I think some people will say a distro is *better* if it releases later. Others will say a distro is better if it releases on a schedule. There have been so many distributions around for so long and yet each of the majors, including both Debian and Ubuntu, have loyal and passionate users. I don't think this is about trying to convince users to switch - they believe in the brands they believe in, to the credit of both groups, not to either detriment. Mark -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Debian decides to adopt time-based release freezes
Pierre Habouzit wrote: On Tue, Aug 04, 2009 at 10:29:11AM +0100, Steve Langasek wrote: I'm sorry that you have a negative impression of Ubuntu's relationship with Debian, but there's plenty of data available that contradicts your conclusion (including BTS reports that have been posted to this very thread). The problem is there is also plenty of data, like for example the recent #539950 (on a package never uploaded to Debian) which is looking a _lot_ like LP#408901. In this bug, the Ubuntu developer is (IMHO) trying to make the Debian one find, fix and patch the bug for him. The problem is (as a DD) that I would expect Ubuntu to collaborate the most on the harder core packages, meaning the toolchain, the kernel, X... Alas, it happens more coincidentally than on a regular basis, and that saddens me. I'm not saying there aren't any working cases of cooperation, and I welcome them. But there are way too many example of bad (or rather inexistant) cooperation, or even dirty tricks like #539950, which undermines the former tries a lot. Pierre, When you have two large, complex, passionate organisations there will always be plenty of opportunities to find fault with one another. Do you not believe that it would be possible to find a long list of cases where Debian developers have acted in a way that made collaboration difficult or impossible, or could be interpreted as bad faith? Of course it would. Nevertheless, we never let those incidents poison our commitment to working better with Debian. On balance, when I look at the huge effort that has gone into better collaboration with Debian, from many core and MOTU developers in Ubuntu, I think we should celebrate those successes and inspire people to do more of that, rather than taking every opportunity to find fault. In this conversation, there are large groups of people who's starting assumption is that Ubuntu is bad, or Debian is difficult, and they find facts to support that assumption. Fair enough, that's human nature. But it will never improve the state of the world to focus on things that people believe are absolute - if you want to improve the state of the world, you need to look for opportunities to make it better. Instead of saying there's a bug that was badly handled, so we should never collaborate better on anything, let's look for opportunities to make things better. We have a good opportunity to make a profound change in the way upstreams and distributions engage. A change that will really help the whole free software ecosystem, and many distributions beyond Ubuntu and Debian. Isn't it worth exploring that idea for its full value? Mark
Re: On syncing freeze dates with other distributions
Bernd Zeimetz wrote: Manoj Srivastava wrote: I also think that we should be looking at when we freeze not merely at when a derived distro freezes, but when major system components release, and when top level sister distributions freeze (we'll get far more benefit for Debian users were we to sync up with fedora/rhel; and have more clout with upstream, especially if Ubuntu sync's up with Debian/red hat as well). Ack. It makes *mucH* more sense for use to keep in sync with fedora/rhel than with Ubuntu. Especially Fedora tries out the very latest funky stuff, it is often really worth the work to have a look what they're doing. At the end this will help Ubuntu, too - if they manage to change their freeze time to an appropriate date similar to the one of Debian. I reached out to RHEL last year to see if they are interested in adopting a predictable cycle of releases, and collaborating around them. They did not respond to the email. I've heard it said informally that they will never do that. In fact, I think RHEL could be persuaded to join such a movement, but only if we have won over almost everyone else first! That's why I've tried to include Novell in the discussion (they are more interested, but still not takers to the idea). Agreeing an approach between Debian and Ubuntu would be a very significant first step. I believe we could then bring in many of the smaller distributions, followed by Novell, and ultimately Red Hat too. Mark
Re: On cadence and collaboration
Hi Marga Margarita Manterola wrote: If Debian commits to a December freeze, would that mean that Ubuntu commits to releasing 10.04 with KDE 4.3 (already released) and GNOME 2.28 (to be released in a few months), instead of KDE 4.4 (to be released in January) and GNOME 2.30 (to be released in March)? This has been one of the main concerns of the December freeze, apart from the fact that we wouldn't meet our release goals, that you are suggesting how to solve. Ubuntu has shown in the past a tendency to ship with the latest versions of software. In the case of GNOME, the freeze in Ubuntu usually happens before GNOME is even released, and yet the latest GNOME goes into the release. So, how would that work in this case? The proposal as I understood it was that in December, the key component maintainers / release managers from all interested distributions would discuss, on a public mailing list, their plans for the base versions of those components in their 2010 releases. It wouldn't be realistic to hope that every distro joins a consensus on every component - there are good reasons why some might want to use a more bleeding edge piece and others may want a more conservative piece. For example, architecture support in Debian might require a different GCC or kernel than the one that everyone else goes with, and that's fine. The rough guide I heard was that, if we looked at the list in December, we'd probably be able to agree on things like the default versions of Python, Perl, X and GCC, but that it might be harder on kernel, GNOME and KDE. That's OK by me - whatever consensus *does* emerge from the process is a win that we otherwise would not have. Some teams may not be ready for the discussion, some might be. That's OK too. My expectation is that Debian will want to have more flexibility in how long the release is baked than Ubuntu would normally give itself. My hope is that we can agree on a GNOME and KDE version, and that Debian will thus benefit from all the work Ubuntu does on that and then have a few extra months (as many as deemed necessary) to bake it to Debian's satisfaction. It is my opinion that freezing after GNOME releases (and gets into testing) would be better for Debian. This means either April or October, depending on which GNOME release we want to ship. If we think, for real, that December is the best month of the year to freeze (I definitely don't), then we would need to somehow convince both GNOME and KDE (and then other upstreams as well) to release in October/November. It's not that much of a change for GNOME, but I don't see this happening this year for KDE. Maybe next year, if this is planned well in advance. The difference in our language is about the meaning of freeze in December. I think December is not about actually freezing, it's about reviewing and planning and looking for opportunities. Certainly, I think the Debian team will want to freeze some things very early (December!), but some maintainer teams may well be willing to commit to using something that will freeze a little later, especially if they can collaborate well with Ubuntu on those packages. But why December? December is a very nasty month to do important things, people go on holidays, stay away from their computers for one, two or more weeks. If anything, I think December is the worst month to plan for a freeze. It's true that Decembers a fractured month, and it would arguably be better to do heavy lifting in another month. I imagine the main work will really be Feb-March, once the decisions are final and widely communicated. In December, by this proposal, we would just have a series of threads on a list like the distributi...@lists.freedesktop.org list, where we try to establish what consensus we can across the major components. It would be planning and discussion, not actually starting the freeze itself except for those components which the maintainers and release managers felt it necessary. Mark
Re: On cadence and collaboration
Julien BLACHE wrote: You are on a fight against proprietary software (you made that clear through your wording in your first mail). One of the issues with proprietary platforms is that everyone running a given platform runs the same security holes. Now, that obviously applies equally if platform = Debian, but not if platform = Linux. There aren't different Windows vendors. There's only one. There are different Linux vendors. If they all offer the same thing, then we have another monoculture and we lose something, something very real. In the free software world, the diversity we have today, which is partly due to unaligned releases from the major vendors, is an asset. You have been talking a lot about the implications at our level and a bit about upstream, but there are implications downstream too that must not be overlooked and they might not be the most obvious. Yes, I would have to agree with your point - having more distributions on the same base version of something like Apache or OpenSSH does increase the risk of a compromise being systemic rather than limited to a particular vendor. The other side to the coin, though, would be the benefits in terms of scrutiny and speed to resolve the issue (produce a patch, at least) when it does happen. But it's a good point. Mark -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: On cadence and collaboration
Marc Haber wrote: Hi, On Wed, Aug 05, 2009 at 09:32:36PM +0200, Jesús M. Navarro wrote: In other words: freeze on december the first doesn't mean that if, say, Gnome will publish it's new shiny 1.2 version by december the 15, the last beta should have to be included, but that the december version will ship version 1.1 (or whatever is the previous known to work stable). It's up to the upstreamer to decide if next time they will publish by november the 15th instead of december the 15th so their latest greatest gets to be shipped. So we basically force a time-based release schedule upon our upstreams when we do time-based freezes? I am not sure whether upstreams are going to like this. No, we give them the opportunity to recommend a version. It might be an older version, or a version they happen to be about to release, it's not *necessarily* time-based for them. We're going to pick a version of their stuff anyway, this just makes it easier to participate in one conversation with many distros about which would work best. I do think more upstreams will adopt time-based releases. Kernel, GNOME, KDE and others are already doing quite well there. X would like to, but is short of manpower on the RM front. Mark
Re: On cadence and collaboration
Marc Haber wrote: On Wed, Aug 05, 2009 at 08:44:29PM +0100, Mark Shuttleworth wrote: My expectation is that Debian will want to have more flexibility in how long the release is baked than Ubuntu would normally give itself. My hope is that we can agree on a GNOME and KDE version, and that Debian will thus benefit from all the work Ubuntu does on that and then have a few extra months (as many as deemed necessary) to bake it to Debian's satisfaction. And you are willing to allow Ubuntu to release with outdated KDE and outdated GNOME, frozen in Dezember, while both upstreams releasing again in January? In the past, so I have been told, Ubuntu has let the current versions slip into the April release We only do this with upstreams which have earned credibility in their release management. Our general policy is that we only accept things which are already an upstream stable release at our upstream version freeze milestone (about two months into the six month cycle). We make exceptions for those upstreams which have a very good track record of actually delivering on time, every time, and being good about freezing early themselves (with appropriate policies for translation and UI freeze, for example). GNOME set the pace on that, KDE is now also looking good. The stronger an upstream's reputation, the easier it is to trust them and plan for a release which they haven't yet delivered when we freeze. I doubt we would lightly trust an upstream that had not already gone through that process once or twice. , which would not be possible if you were syncing with Debian. Well, given that Debian will typically take longer to be satisfied with a release (more architectures, more packages considered RC, different approach to QA, volunteer team) it may well be possible to agree to freeze on something which is not yet released in December, but will be released early enough to give both Ubuntu and Debian confidence that it can be a shared component. Or do you expect that we would let new KDE and new GNOME into a distribution frozen two months earlier to accomodate Ubuntu? No, I wouldn't expect that, it wouldn't make sense or be congruent with Debian's values. If you mean that Debian continues its staged freeze, starting with the toolchain in December, followed by other stages and the last stage including the desktop environments in february, do you seriously expect us to release before October? That would be overly optimistic, we're not that fast. Well, I agree that prior staged freezes haven't been ideal, but I think the basic idea has merit, especially in collaboration with other distributions and upstream. And, even if we were that fast, Ubuntu LTS would be on the market half a year earlier, giving Ubuntu a strong advantage over Debian stable. We've been in that situation in the past, for example with Ubuntu 6.06 and Debian Etch, and it didn't make much difference. Mark
Re: On cadence and collaboration
Noah Meyerhans wrote: I think it's reasonable to believe it would be easier to get [upstream] attention about a version that *many* distributions adopted. Additionally, even if upstream isn't willing to provide any help to distros shipping what they consider to be a stale version, the distros are in a better position to help each other if they're shipping similar versions. Yes, I agree very strongly.
Re: On cadence and collaboration
Jan Hauke Rahm wrote: I understand you've been talking to other distributions as well about syncing releases (or freezes) in order to ship same versions of major system components. Now, much of the discussion here is about the actual dates, i.e. the possible freeze in a few month as well as freezing in the end of odd years to release in spring of even years. This idea seems to fit best to your (ubuntu's) current release cycle and I feel many Debian contributors see there your (inacceptable?) influence on Debian. I'm interested in the reactions of other distributions. Are they likely to change their release cycle to fit yours? Or would you be willing to change Ubuntu's release dates if SuSE proposed LTS releases to come out in odd years or similar? I think most are waiting to see if Debian and Ubuntu can do this. If we can, I am very confident we will get a group of other distributions participating in the version harmonisation discussions in the first round. To win Novell we would have to actually demonstrate the process works, I think. And to win Red Hat we would need to demonstrate it works with everyone else first. At least, that's my impression from conversations to date. Mark
