Re: info on debian packaging and installer
On Wed, Aug 05, 2009 at 09:54:30AM +0530, Vinoth vijaybabu wrote: Hi, I am vinoth, and i am trying do a project called packaging and installer, and i want create my own debian packaging and installer. Can you help to do this. -- V.Vinoth Vijaybabu This mailing list, debian-project, is for Discussion about non-technical topics related to the Debian Project.. Try contacting the following mailing list and getting the manuals: Debian installer developers have their own mailing list, http://lists.debian.org/debian-boot/ Debian packaging: http://www.debian.org/doc/maint-guide/ -- Tapio Lehtonen tapio.lehto...@iki.fi http://www.iki.fi/tapio.lehtonen signature.asc Description: Digital signature
Re: Debian decides to adopt time-based release freezes
On Tue, Aug 04, 2009 at 11:49:09AM -0500, Manoj Srivastava wrote: Perhaps Ubuntu should correct it's web page, then, in light of the apparent fact that automatic feeding of patches upstream is not in fact reality? Yes, I've forwarded this bug to the attention of the Ubuntu webmaster. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- 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
Mark Shuttleworth m...@ubuntu.com wrote: [Cc:ed as I don't know whether you're subscribed to -project] Hi, freeze summit, and there are significant benefits to Debian to being part of that rather than on a different schedule. 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. Overall, it's been working fine for the last 16 years. 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. Once I've removed that from your mail, and the but Ubuntu loves you! stuff, there's nothing left. JB. -- Julien BLACHE - Debian GNU/Linux Developer - jbla...@debian.org Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- 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
Mark Shuttleworth m...@ubuntu.com wrote: Hi, 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. If we were tied to something or someone one way or another, this would not be possible. 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. 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. JB. -- Julien BLACHE jbla...@debian.org | Debian, because code matters more Debian GNU/Linux Developer| http://www.debian.org Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
On Torvalds' POV towards freedom (Re: On cadence and collaboration)
Hi Mark, Sorry that I don't comment on your proposal, as I'm not really the most indicate, except to say I appreciate it, and I hope it's succesful. But there's something I'd really like to comment on. On Wed, Aug 05, 2009 at 10:21:38AM +0100, Mark Shuttleworth wrote: I enjoyed Linus Torvalds' recent interview where he talked about prejudice against Microsoft in the Linux community, and how poisonous it is. The same is true of prejudice against Ubuntu here in Debian. I think you're misscharacterizing Torvalds' statement. He said that hatred is a disease, but that's a generally agreed upon fact, and I don't think it's the core of his message. He also said: There are ‘extremists’ in the free software world, but that’s one major reason why I don’t call what I do ‘free software’ any more. I don’t want to be associated with the people for whom it’s about exclusion and hatred. which basically amounts to: If you speak about freedom, you're an extremist full of hate. Torvalds' message is that of an extremist itself. In Torvalds' mind, it is not conceiveable that people care about freedom out of love, and that they don't hate anyone because of it. In his narrow view of reality, standing and defending your rights is the same thing as hating the person who'd take them away from you. Mark, since you speak about free software yourself, I assume you don't adhere to this point of view. I think it would be in your best interest to watch carefully before subscribing to something this person said. Thanks -- Robert Millan The DRM opt-in fallacy: Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: On Torvalds' POV towards freedom (Re: On cadence and collaboration)
On Wed, Aug 05, 2009 at 02:12:24PM +0200, Robert Millan wrote: Hi Mark, Sorry that I don't comment on your proposal, as I'm not really the most indicate, except to say I appreciate it, and I hope it's succesful. But there's something I'd really like to comment on. On Wed, Aug 05, 2009 at 10:21:38AM +0100, Mark Shuttleworth wrote: I enjoyed Linus Torvalds' recent interview where he talked about prejudice against Microsoft in the Linux community, and how poisonous it is. The same is true of prejudice against Ubuntu here in Debian. I think you're misscharacterizing Torvalds' statement. [...] which basically amounts to: If you speak about freedom, you're an extremist full of hate. Nice. -- Intersec http://www.intersec.com Pierre Habouzit pierre.habou...@intersec.com Tél : +33 (0)1 5570 3346 Mob : +33 (0)6 1636 8131 Fax : +33 (0)1 5570 3332 37 Rue Pierre Lhomme 92400 Courbevoie -- 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 jbla...@debian.org writes: 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. I take it then that another part of Mark's message you discarded was the part where he explained the goal is to discover and better advertise existing opportunities to collaborate, and *not* to have one project “restricted” by another. 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. Right. If they gave that answer, I'd be responding “you didn't answer the question: what would you do differently?”. -- \ “For of those to whom much is given, much is required.” —John | `\F. Kennedy | _o__) | Ben Finney -- 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
On Wed, Aug 05, 2009 at 09:04:46AM +0100, Steve Langasek wrote: I'm not sure whether this subthread is really going anywhere, given that it seems to have devolved into a complaint about the handling of a particular bug, and playing whack-a-mole on a public mailing list in response to individual interactions seems a thoroughly ineffective way to change anything about the Debian-Ubuntu relationship at large. Still, given that I have personal knowledge of the bug in question, I can't help but respond... The bug is actually not a single bug but reflects the cooperation between Ubuntu and Debian on the eglibc side. It may be different in some other areas, but it reflect my daily feelings. On Tue, Aug 04, 2009 at 11:18:26PM +0200, 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 package has not yet been uploaded to Debian, but the package that was uploaded to Ubuntu is based on the Debian repo where eglibc 2.10 is being staged for upload. Why do you conclude that the Ubuntu developer is trying to make Debian find and fix the bug? Do you think that Ubuntu developers should only communicate with Debian about bugs they already know the fixes for, and that anything else implies that Ubuntu is expecting Debian to fix the bug for them? Is sharing information about known bugs not *also* a useful form of collaboration? Do you think Ubuntu developers should not communicate with Debian developers about possible upcoming regressions? Or are you only arguing that such communication should not take place in the BTS? (I can certainly sympathize with the latter, since using non-existent version numbers when filing bugs in the BTS is effectively garbage data; I'm just not clear exactly what your objection is in this case.) Given that this is almost certainly an upstream bug, and a regression vs. 2.9, I would think that the Debian maintainers would, in the general case, welcome being kept in the loop about such a bug. If that's not true, how should the Ubuntu developers know this? In this instance, the bug was forwarded to Debian by a developer who does a significant proportion of the glibc work in Ubuntu, and is not an unknown entity to the Debian glibc maintainers. If the Debian glibc maintainers don't want to receive warning about such upcoming issues, or want to receive it by other means, has any effort been made to communicate this to Matthias? (Posting to debian-project certainly doesn't count...) How in the general case is Ubuntu developer X supposed to know whether Debian maintainer Y is going to welcome being kept apprised of upcoming problems they will face when upgrading to a new upstream version, or will instead regard it as a dirty trick? In an ideal world seeing such a bug report in the Debian BTS would have been appreciated. In practice, except a few minor exceptions, the code always flows from Debian to Ubuntu, so I clearly have some a priori. I have been personally informed about this bug about 15 minutes after it has been submitted in the Ubuntu BTS, thanks to IRC. I usually get informed about problems on the Ubuntu side that way, and until recently I answered or fixed them depending on my *free time*. In short Ubuntu is doing cosmetic tweaks to the packaging, and Debian is maintaining the packaging, writing patches, and does most of the interaction with upstream. Add to that Debian is currently lacking manpower to follow the rate of the bug reports. With all those reasons, seeing a bug report from Ubuntu without much analysis than in the original bug report really makes me think Ubuntu wants to see the bug fixed by Debian. I am pretty fine cooperating with Ubuntu, provided that Ubuntu adds some manpower to do part of the job. 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. With the exception of the kernel, where the packaging is more or less a complete fork between Debian and Ubuntu, I think all of these components are areas where Ubuntu developers collaborate. Many of the packages are often in sync between Debian and Ubuntu (with experimental if not with unstable), changes originating with Ubuntu are frequently made available in both Debian and Ubuntu simultaneously when feasible, and when not, the
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
[ Marc Haber ] 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. Kind of a personal reply? Considering all of the accusations, and the snide, cynical, and sarcastic remarks, I'd say it's quite personal. Maybe it's just me, but I don't see anything in your response that adds anything to the discussion. If you feel compelled to send such personal replies, could at least spare the list? Thanks. 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 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. 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. 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. 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. As pointed out on this list, Debian and Ubuntu share a great deal. I wouldn't call that share. 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. (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. 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. . When I look over the commentary on debian-devel and in debbugs and on #debian-devel, I see a lot of familiar names from Ubuntu, especially on the deep, hard problems that need solving at the core. From new people that weren't hired over to Ubuntu from Debian? So, practically, we would be in a good position to collaborate. Of course. Ubuntu _is_ Debian in a very big part. I see mails on this list saying it would be easier and better for Debian to coordinate with distributions that I think would be almost *impossible* to work with practically, It is almost impossible to work with Ubuntu as soon as one doesn't agree. How do I think it could work in practice? Well, if Debian and Ubuntu went ahead with the summit in December, where we reviewed plans for 2010 and identified opportunities to collaborate, I think we would get (a) several other smaller distributions to participate, and (b) several upstreams to participate. You're a true visionary. A December summit is not about tying anybody's hands. It's about looking for opportunities, where they exist naturally, and communicating those more widely. At least Debian has epically failed in wide communication of this decision by first putting out a press release before informing
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: On cadence and collaboration
Hello, Mark Shuttleworth wrote: 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. the independence is not necessarily planned. To my perception it is more of a I am using my current distro which I know well and quickly (or less quickly) and incrementally improving a package of my interest as good as I can without looking much left, right or down to other dis(s)tros. We are all (mostly) volunteers and often the looking left or looking right takes much more time than the packaging itself. And in my view, this is mostly fine this way. In a perfect world, upstream collects packages from the distributions quickly, at least those that matter. And they would all read the bug reports that the distributions collect and react to them - many thanks for launchpad, btw. The thinking of releases I hope to disappear in some not so distant future. This would then render all this discussion rather irrelevant, right? Instead, we should have packages collected on our machine, whose cutting-edginess depends on the users' personal skills and interests. This would be similar to stable with backports on for selected packages only. Many greetings Steffen -- 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
On Wed, Aug 05 2009, Mark Shuttleworth wrote: Thanks for the input. This was a far gbetter reasoned mail than some that have appeared on the list. 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? 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 :-) Based on Debian's last two releases, I think we have a 22 month release cycle going; stretching it to 24 years is not a big deal. Speaking for myself, I think have a predictable freeze date, every two years, is a good thing. I do have objections to starting that with a foreshortened release cycle, and while I am neutral about December as a freeze month in general, I suspect that the the actual date should come after negotiating with major component package maintainers (and upstream), and efforts in house aimed at improving Debian, and, ultimately, other distributions. So yes, I concur. How do I think it could work in practice? Well, if Debian and Ubuntu went ahead with the summit in December, where we reviewed plans for 2010 and identified opportunities to collaborate, I think we would get (a) several other smaller distributions to participate, and (b) several upstreams to participate. That would be a big win. It would set us off on a good course. If we delivered, then, we would virtually guarantee that almost all the distributions and key upstreams would participate the next time around. And if *that* worked, we'd win RHEL over too. Umm, what summit is this? I think this is something that the Debian developer community has not been told about yet (which is somewhat irritating, but that is the theme for a different thread). First, there has been no secret cabal or skunkworks effort to influence Debian. As best I can tell, folks from both Debian and Ubuntu who have deep insight into release management established a shared interest in working together better, at many levels, and this was one idea that came forward. The fact that those discussions were open and ongoing was no secret - I wouldn't have talked about it in the media if it were! (Ironically, someone suggested that the fact that I was talking publicly about something in Debian implied there was a secret cabal. Aiieee.) Well, the proof of the pudding is in the eating, no? The fact that the majority of the developers have expressed a complaint that they were not in the loop seems to indicate that the non secret bit has yet to be adequately demonstrated. This reminds me of a notice that was on display on the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying 'Beware of the Leopard. Third, I think we need to call on the people who are not fundamentally prejudiced to speak out. As long as criticism does not immediately accrue the label of bias, this is fine. Now, if, as in a previous mail from you, synchronization implies that people are agreeing to ship with the same versions of the tool chain, X, KDE/GNOME, and other major components, that would mitigate some of the worry heard on this list about Debian being taken advantage of. Of course, determining what version of these packages will ship in a release needs to involve the maintainers and upstream developers of the package in question, with the RM's having a deciding role in what does or does not make the cut (decision after consultation is a horse of a different color than a priori decisions). I currently object to shortening the current release, causing various teams to shelve their ongoing improvements and development plans, in order to hasten towards a sync process that has not even begu the process of deciding on which versions of major packages we will ship (and, personally, what the status of the reference selinux security policy shipped will be). I see this as a good point to start discussion, not as a point where we decide to freeze in four months or so from now. manoj -- There are two kinds of egotists: 1) Those who admit it 2) The rest of us Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Opera in your repos
Hi, I work in Opera Software - yes, we make a proprietary browser ;) Last 7 years I use GNU/Linux and know that, for example, in Russia the Opera browser is very popular in GNU/Linux Community. Unfortunately, not always I can see this browser in the non-free repos. Well, there is a question: whether Opera is included to your distro and if not - how we can fix this problem? We are ready for any discussions, technical help or agreement, if necessary. Thanks in advance, -- Best regards, Ilya Shpan'kov Community Outreach Manager for Russia Opera Software ASA Mobile: +47 46351421 Web-site: http://my.opera.com/IlyaShpankov/ Skype: shpankov -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Opera in your repos
(Beware sarcasm tags might be missing.) Ana Guerrero a...@debian.org (05/08/2009): Even in the case you release the opera code with a license that allow distributing opera in non-free, there is not much point on distributing it when we already have _totally free_ browsers. There is: Linux is about Choice! Mraw, KiBi. signature.asc Description: Digital signature
Re: Opera in your repos
On Wed, 5 Aug 2009, Ilya Shpan'kov wrote: Hi, I work in Opera Software - yes, we make a proprietary browser ;) Last 7 years I use GNU/Linux and know that, for example, in Russia the Opera browser is very popular in GNU/Linux Community. Unfortunately, not always I can see this browser in the non-free repos. Well, there is a question: whether Opera is included to your distro and if not - how we can fix this problem? We are ready for any discussions, technical help or agreement, if necessary. As explained by Ana, Debian is about making a free operating system, so we usually try to remove software from non-free when we have free alternatives, not add more. Anyway, I'll give you a more technical answer. I see at least two problems in putting Opera in non-free: First one, the End User License Agreement does not say anything about redistribution. It is allowed at all? Under which conditions? Do those conditions last forever, or may Opera Software terminate them at their wish? Bear in mind that there are sites like snapshot.debian.net that would copy each and every upload of opera from non-free to be archived forever. If we can't do that it would probably not worth the effort. The second problem I see is the discrimination against some users. From the LICENSE text: You are entitled to use the Software on all personal computers (laptops/desktops). Use means loaded in temporary memory or permanent storage on the computer. You may not use the Software on non-PC products, devices, or embedded in any other product, including, but not limited to, mobile devices, internet appliances, set top boxes (STB), handhelds, PDAs, phones, web pads, tablets, game consoles, TVs, gaming machines, home automation systems, or any other consumer electronics devices or mobile/cable/satellite/television or closed system based service. Well, the fact is that Debian aims to run on all those devices too. Putting opera.deb in non-free would be deceptive to those users, as most people assume that if something is in non-free, then the software might be proprietary but at least use is not restricted, which would not be the case here. As Debian is about creating a free operating system, we don't have any system or procedure to force people to accept licenses before dowloading packages. With current tools, whoever bothers to package Opera for non-free would probably add a debconf question in the line of Are you using an ordinary PC (laptop/desktop) or you are using something else?. If I had to answer questions like that after installing something, I am not sure I would be glad of doing so from a Debian server. Thanks. -- 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
Eric Evans eev...@sym-link.com wrote: Hi, Maybe it's just me, but I don't see anything in your response that adds anything to the discussion. You can see Marc's reply as documentation for people new to this matter. There's some value in that. JB. -- Julien BLACHE - Debian GNU/Linux Developer - jbla...@debian.org Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Opera in your repos
On Wed, Aug 05, 2009 at 07:10:48PM +0200, Cyril Brulebois wrote: (Beware sarcasm tags might be missing.) Ana Guerrero a...@debian.org (05/08/2009): Even in the case you release the opera code with a license that allow distributing opera in non-free, there is not much point on distributing it when we already have _totally free_ browsers. There is: Linux is about Choice! Like choosing not to give support to propietary stuff ? :D Ana -- 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 mh+debian-proj...@zugschlus.de writes: On Wed, Aug 05, 2009 at 10:21:38AM +0100, Mark Shuttleworth wrote: 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. I have. Furthermore, even upstreams that currently aren't interested in cooperating with distributions I suspect would change their minds if they could support *one* long-term stable release. It might take a few years for them to come around, but it starts looking very appealing. I'm skeptical about whether we can get there, but I think Mark's analysis is fundamentally correct. As pointed out on this list, Debian and Ubuntu share a great deal. I wouldn't call that share. I've had almost uniformly positive experiences working with Ubuntu users of the packages that I maintain and integrating those packages into Ubuntu, including valuable contributions and improvements that originated in Ubuntu and were filed as bugs against the Debian packages (although since I subscribe to all of the Ubuntu packages corresponding to my Debian packages in Launchpad, I normally short-circuit that). My corner of Debian would be noticably worse if it were not for Ubuntu, and this is from someone who has never run Ubuntu and has no interest in ever doing so. At least Debian has epically failed in wide communication of this decision by first putting out a press release before informing the community itself. Which, of course, is not Ubuntu's fault. Problems with communication internal to the Debian project are not ones that Mark Shuttleworth can solve, or should attempt to solve. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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
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 Mark, thanks for the time you spended on this mail to improve cooperation. I'm currently under time pressure - so I pick only a few points. in my answer. Please assume general agreement to your reasoning about the needs of cooperation. On Wed, Aug 05, 2009 at 10:21:38AM +0100, Mark Shuttleworth wrote: 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. 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. Thanks for this! create divide and disharmony. I stayed away from DebConf this year - the first time in six years - because I didn't want to be a flashpoint for division, Ups, the reason for you to stay away to not be a flashpoint makes me somehow sick. I was wondering about your reasons - it's a shame if this would be the main point. To achieve anything together, we'll both need to work together, we'll need to make compromises or we'll need to contribute effort to the other side. If the Debian community is willing to consider a December freeze, then Ubuntu (and Canonical) will commit resources to help Debian meet that goal. It means we'll get less done in Ubuntu, but the benefits of having a schedule which could attract many other distributions would outweigh that. I really really agree here. My position was always that the diff between Debian and Ubuntu should be as small a possible and IMHO this is a great step in this direction (and I think I'm speaking here more in the interest of Ubuntu than in the interest of Debian - at least this is my personal view on the issue). Thanks for your extensive mail. I read some frustration out of it and I hope that only a minority in Debian will give reasons to become frustrated. Hope to see you at any other event (but did not made up my mind about DebConf 10) Andreas. -- http://fam-tille.de Klarmachen zum Ändern! -- 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
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=1318967cid=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
Re: Debian decides to adopt time-based release freezes
Steve Langasek wrote: Does that mean you don't think Ubuntu developers contribute fixes back to Debian today? As security, contributing fixes back to Debian is not a product nor a state, it's a process. We should all be interested in optimizing this process further. http://patches.ubuntu.com/ indeed makes the packages easier to merge but it is not as powerful as our patch tracking system [1]. One possible step to improve the situation could be a similar service provided by Ubuntu based on the work which already has been done by Sean Finney. The source code is available in a public repository and it is GPL2 licensed. After such a service would have been implemented one could think about things like adding a special tag to patch headers to recommend these patches to be merged by Debian. It could also be useful to be able to specify how strong such a recommendation is. Is there already a (wiki) page which describes how a Debian maintainer can track his packages in Ubuntu or how to handle Ubuntu originated bugs? If this is the case it should be promoted better, e.g. in Misc Developer News. Carsten [1] http://patch-tracking.debian.net/ -- 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
Mark Shuttleworth m...@ubuntu.com wrote: 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. Releasing (or freezing, FWIW) at the same time as everyone else is a part of that. Your developement then becomes bound in just the same way as everyone else's, with all the consequences you can think of. As the ultimate goal is to get pretty much all the free software world to sync up for distro releases, this means everyone will work on the same fixed schedule (with ca. 2-year development periods). I'm wondering about the impact this will have on roadmaps in different projects. I fear it may bring to free software some of the worst issues of the proprietary/commercial software world (no vision past the next big release, for instance). 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. I'm not sure our governance model is of much interest to the lambda end-user, she probably also doesn't give a damn about debian-legal and architecture support. 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. If it works that way already, why bother? Also, what are we really talking about here? Desktop? Is that it? All of this seems very desktop-centric to me. What's the story on the server front, and what are the implications? Do we set an Apache version everybody will ship, too? What impact does that have on security? When everyone gets the same Apache version accross all distributions, with the same issues? Does that buy us anything? Isn't diversity better here? 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. 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 Wishful thinking. Community members can also rally to the most popular proposer, regardless of the proposal she puts forward. Not meant at you, but to illustrate that things don't necessarily work as they should. 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? I get your point. JB. -- Julien BLACHE - Debian GNU/Linux Developer - jbla...@debian.org Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- 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
Hi, Julien: On Wednesday 05 August 2009 20:42:03 Julien BLACHE wrote: Manoj Srivastava sriva...@debian.org wrote: Hi, 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. But most of these will not be lost if we have a time based I think we'll lose part of the we release when it's ready philosophy (that our RMs seem to despise so much). Because part of this is to freeze when it's ready. Not at all if done properly. Freeze on a date simply means that what it's ready on that date is included, what it's not ready won't be included, simply as that. When you couple that with a freeze date well known in advance, you allow interested people to plan properly. 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. The fact that they'll know well in advance when the freeze is to be expected is what will allow them space enough to make a savvy decision while now, with the freeze when ready is a matter of luck and a point of friction (pleeease, wait for another two weeks for our new and shinny). A time-based freeze could mean for some teams that they'll have to stop work basically for months to a year. It already takes too much time to recover after a release, this won't help. Why? I really don't see your point unless you mean for the packager under current conditions where no real branches are allowed on Debian (but the everbody's bag that it is 'experimental' that has demonstrated not to be a solution at all). This needs to be changed and I expect the time-based freeze to be the tick that will finally push this change. I envision a system where a new upload will create kind of a branch and trigger a dependency cascade where all dependent (depend, suggest and recomend) packages are alerted so their maintainers can test for obvious problems and ack the upgrade or release a new change on the branch that again triggers the dependency cascade for its dependants. Once everybody acks or upgrades the whole branch gets commited into what currently is testing (the ack mech will in turn help for the MIA case: an unanswering maintainer would -under proper conditions, automatically meant for the package to be orphaned or even retired; a maintanier whose last package goes that way would be automatically marked for MIA process). This way, you could freeze testing almost any day without problems (and Ubuntu could easily go on their own if in the end that's better for their interests, since the health of testing would be much better any day going almost without the upgrading storms current process almost guarantee on testing from time to time). If that's what you meant, I think you don't have an argument against time-based freezes but against the first time-based freeze on Dec-2009 but to push it to a latter date in order to have time for the tools to be developed (hey, Mr. Canonical, there you have a very interesting case where your hands and moneys would certainly be more than welcome). In this day and age, you have to look at features in addition to the version number, because the latter isn't necessarily very telling of the real changes from one release to another. Major features are delivered in minor releases nowadays... I already said that to be simply malpractice and beyond a distribution's ability to correct (while I'm with Shuttleworth in that concurrent freezes would help to show the proper path to upstreamers). -- 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
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
Hi Mark, I apologize if this was already said somewhere; somehow I've got lost in this hundreds of mails... :) On Wed, Aug 05, 2009 at 03:48:06PM +0100, Mark Shuttleworth wrote: No, as I wrote separately, this is more about signalling an emerging cadence across multiple distributions. For many reasons, it's easier for more commercial organisations to plan in years, and the proposal from the Debian release team happens to make that work well. [...] Mandriva would be a likely candidate to participate as well. And I think SUSE could be convinced if we can get past this debate, too. 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? Hauke signature.asc Description: Digital signature
Re: On cadence and collaboration
Jesús M. Navarro jesus.nava...@undominio.net wrote: Hi, I think we'll lose part of the we release when it's ready philosophy (that our RMs seem to despise so much). Because part of this is to freeze when it's ready. Not at all if done properly. Freeze on a date simply means that what it's ready on that date is included, what it's not ready won't be included, simply as that. When you couple that with a freeze date well known in advance, you allow interested people to plan properly. The freeze date for the past few releases has always been known in advance and refined as we went. The problem is that a lot of upstreams do not have a planning that we can compare against and base our work upon, so for a lot of the packages we just follow upstream. Not to mention our very own infrastructure issues that have bitten us. (pleeease, wait for another two weeks for our new and shinny). That's largely an end-user-induced issue, desperately trying to escape the Debian obsolete nickname for Debian stable. We're weak ;) A time-based freeze could mean for some teams that they'll have to stop work basically for months to a year. It already takes too much time to recover after a release, this won't help. Why? I really don't see your point unless you mean for the packager under current conditions where no real branches are allowed on Debian (but the That's exactly my point. We suck at freezing. everbody's bag that it is 'experimental' that has demonstrated not to be a solution at all). This needs to be changed and I expect the time-based freeze to be the tick that will finally push this change. It all boils down to the current testing system being inadapted to our needs. But that's something we couldn't really know for sure until we had tried it for a couple of releases, and I think we still won't know for a release or two because of the new tools that have been put in place to handle transitions (and others). If that's what you meant, I think you don't have an argument against time-based freezes but against the first time-based freeze on Dec-2009 but A lot of things need to line up for a release. Debian is very large and the windows of opportunity are few and small. Deciding on versions of core packages between distributions could help, but a fixed-date freeze probably won't. It could even make things worse, as it could make it harder to iron out the issues (like having to convince the release team to let a new upstream in to fix something because there's really no better way). Seriously, everybody gets bored and fed up during a freeze. I am of the opinion that no matter how hard you try, you can't *make* a Debian release happen. There's some point at which the release starts to happen, a point where a critical mass of DDs is reached, the point where everybody uses the word release more than any other word. to push it to a latter date in order to have time for the tools to be developed (hey, Mr. Canonical, there you have a very interesting case where your hands and moneys would certainly be more than welcome). Remember dunc-tank? In this day and age, you have to look at features in addition to the version number, because the latter isn't necessarily very telling of the real changes from one release to another. Major features are delivered in minor releases nowadays... I already said that to be simply malpractice and beyond a distribution's ability to correct (while I'm with Shuttleworth in that concurrent freezes would help to show the proper path to upstreamers). What we'd need is some sort of upstream academy where we could teach upstream: - how to version properly - how to properly manage their API/ABI for shared libraries - how not to make a mess of their release tarball - ... (let's not make a list, it'd be depressing) JB. -- Julien BLACHE - Debian GNU/Linux Developer - jbla...@debian.org Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
freezing in december and holidays (was: On cadence and collaboration)
also sprach Manoj Srivastava sriva...@debian.org [2009.08.05.1708 +0200]: I do have objections to starting that with a foreshortened release cycle, and while I am neutral about December as a freeze month in general, I suspect that the the actual date should come after negotiating with major component package maintainers (and upstream), and efforts in house aimed at improving Debian, and, ultimately, other distributions. Freezing in December means that the first 2-3 weeks after the freeze will be mostly lost in terms of preparing a release due to holidays. In my 10+ years of Debian experience, the Christmas time has usually been the lowest activity time each year. -- .''`. martin f. krafft madd...@d.o Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduckhttp://vcs-pkg.org `- Debian - when you have better things to do than fixing systems all i know is that i'm being sued for unfair business practices by micro$oft. hello pot? it's kettle on line two. -- michael robertson digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Re: On cadence and collaboration
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. Greetings Marc -- - Marc Haber | I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things.Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 3221 2323190 -- 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
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, which would not be possible if you were syncing with Debian. Or do you expect that we would let new KDE and new GNOME into a distribution frozen two months earlier to accomodate Ubuntu? 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. 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. 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. This still looks like marketing suicide for Debian to me. Greetings Marc -- - Marc Haber | I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things.Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 3221 2323190 -- 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
Le mercredi 05 août 2009 à 20:25 +0100, Mark Shuttleworth a écrit : At the micro-level, across the long tail of thousands of packages, I don't expect there to be detailed coordination through a process like this. The main benefit would come from the smaller set of core infrastructure packages that generate a lot of bugs and maintenance issues. Things like: - Python - 2.6, 2.7, 3.2? Now, that's not a large percentage of the archive, but they are all things that have a lot of consequences, and differences there drive a lot of other packaging differences (especially things like Python). If you want your examples to be meaningful, please don’t invoke cases where a Canonical employee is specifically holding back development in Debian. Cheers, -- .''`. Josselin Mouette : :' : `. `' “I recommend you to learn English in hope that you in `- future understand things” -- Jörg Schilling signature.asc Description: Ceci est une partie de message numériquement signée
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
Julien BLACHE jbla...@debian.org writes: Marc Haber mh+debian-proj...@zugschlus.de wrote: [1] and I am actually quite disturbed that Mark gets to talk to the DPL more often than Debian does Bah, journalists get to talk to him even more often, especially the hacks at The Register. I learned quite a few things by reading papers on The Register. Disturbing, indeed. I suspect, in both cases, that has something to do with who is actively seeking him out. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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: 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
Re: On cadence and collaboration
On Wed, Aug 05, 2009 at 09:30:33PM +0200, Julien BLACHE wrote: In the free software world, the diversity we have today, which is partly due to unaligned releases from the major vendors, is an asset. Security-wise ? Let's admit that, I don't want to fight on that point, even if I think it's not as simple. But speaking from my experience as an employee of a software editor, I can tell that the distribution diversity is a huge problem when it comes to distributing our work. If your client use a Ubuntu LTS, a RHEL, a SuSE or worst for some, some kind of home-brewed monster taken half from a RHEL and custom packages (*sigh*) then you have as many builds to do, regress-test and so on. When you target Windows or Solaris or MacosX, you usually officially support the last two releases, and that's it (and please, it's the same for Linux distributions, for RH you have to support RH4.x and RH5.x if you want to be relevant). It yields a really costly entry point to target Linux as a platform, and it's exactly why most Software Vendors target RHEL and not Linux. And that's part of the reason[1] why most of our customers are using RHELs: software vendors only certify their stuff for RHEL, because it's the established reference in the field, and that it costs too much to certify you stuff for yet-another-distro. OTOH, the diversity is also good for us, and there isn't two developers with the same distribution: many Debian sid's, but also lennies, even a gentoo IIRC, and it has proven a good thing to find awkward bugs in our software. But if this diversity is good for the development phase (and can easily achieved using unstable-like distributions), it sucks a lot when it comes to distribution. Bottom line, I think your vision of the problem is too blackwhite. Of course, arguably we shouldn't care about proprietary software. But let's face it, in the end, people will want to make their Oracle cluster work, make their funky Telco hardware work with a proprietary stack and so on. [1] quality of the support is clearly the other biggest part -- Intersec http://www.intersec.com Pierre Habouzit pierre.habou...@intersec.com Tél : +33 (0)1 5570 3346 Mob : +33 (0)6 1636 8131 Fax : +33 (0)1 5570 3332 37 Rue Pierre Lhomme 92400 Courbevoie signature.asc Description: Digital signature
Re: On cadence and collaboration
Julien BLACHE wrote: That'd break common enterprise setups like having 2 firewalls running different distributions. Not sure how you get around that once all the distros commonly used/accepted in the enterprise world agree on shipping the same version of server software. Using two different versions of software is IMO no boon to security for a series of reasons: - Having a single compromised firewall is enough. - There's no guarantee the different versions won't be affected by the same security issues. - There's more management work to follow the possible vulnerabilities, which could be seen as making attack surface bigger. - Not to mention the lack of support, which has already been used as an argument: since it's unlikely upstream would provide security updates for two versions the burden would fall on the distro and the timeframe for exploits gets a bit bigger. But even if I'm wrong - which I could easily concede - this doesn't serve as argument, since you could just as easily use two different versions of the same distribution, specially in scenarios where you can deploy LTS and STS versions concurrently. This would ease the management overhead and still keep the theoretical security gains. Cheers -- Leo costela Antunes [insert a witty retort here] signature.asc Description: OpenPGP digital signature
Re: On cadence and collaboration
[Julien BLACHE] I think we'll lose part of the we release when it's ready philosophy (that our RMs seem to despise so much). Because part of this is to freeze when it's ready. I still don't understand what is supposed to be new about the time-based freezes. The Release Team was giving us projected freeze dates all through the lenny release. For example, http://lists.debian.org/debian-devel-announce/2008/02/msg2.html Of course we weren't able to hit every freeze date ... but so far I haven't seen any reason to believe that aspect of Debian will change. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: On syncing freeze dates with other distributions
Mark Shuttleworth wrote: 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). Did you give fedora a try? I could imagine they're much more open to such suggestions. 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. As long as it is ensured that Ubuntu *AND* Debian profit from it, it would be good to have. Unfortunately various Ubuntu-related things had imho a pretty bad influence on Debian (I'm saving the time to repeat them here, there are enough mails from various people from the last days stating the problems), so it is not easy to convince me. -- Bernd Zeimetz Debian GNU/Linux Developer GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Opera in your repos
Ilya Shpan'kov wrote: Thanks, Santiago! I will inform our lawers about your opinion. Really, it have a very big sense. I can say, that here in Opera we had discussions about being Free Software every year. Unfortunately, we have a lot of agreements with other companies which use Opera at their devices - by this case we still can't to be a real free Software. It would be *really* amazing if Opera would become free software. The browser is really awesome, but as it is not open-source software, I rarely use it. -- Bernd Zeimetz Debian GNU/Linux Developer GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- 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
On Wed, Aug 05, 2009 at 02:07:22PM -0700, Russ Allbery wrote: Julien BLACHE jbla...@debian.org writes: Marc Haber mh+debian-proj...@zugschlus.de wrote: [1] and I am actually quite disturbed that Mark gets to talk to the DPL more often than Debian does Bah, journalists get to talk to him even more often, especially the hacks at The Register. I learned quite a few things by reading papers on The Register. Disturbing, indeed. I suspect, in both cases, that has something to do with who is actively seeking him out. To be fair, I've not been doing a good enough job of talking with the project as a whole lately. I *have* been talking to a lot of people inside and outside Debian about things in that time, but a combination of a very busy day job and a new girlfriend have been keeping me much quieter than I was planning for. I've also deliberately been ignoring a lot of the crap on our mailing lists rather than diving in to feed flames in the arguments. Maybe some people think that's a bad thing. -- Steve McIntyre, Cambridge, UK.st...@einval.com Is there anybody out there? -- 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
On Wed, Aug 05, 2009 at 08:42:03PM +0200, Julien BLACHE wrote: I think we'll lose part of the we release when it's ready philosophy (that our RMs seem to despise so much). Because part of this is to freeze when it's ready. If you don't have an idea of what to target for your release (or when to target your release), then the release doesn't actually happen. We've seen that happen in the past. The Etch and Lenny release cycles worked OK for us and were specifically aimed at 18-24 schedules. Or would you claim that they weren't ready? Freezing to a schedule will still give us all the control we need in terms of actually stabilising for release. A time-based freeze could mean for some teams that they'll have to stop work basically for months to a year. Exaggeration, -1. -- Steve McIntyre, Cambridge, UK.st...@einval.com We don't need no education. We don't need no thought control. -- 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
Hi, Marc: On Wednesday 05 August 2009 22:24:56 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. Force? No!!! How in hell could a user (a user of a royalty-free, freely distributable software no less) force anything on the provider? It's the other way around if any! *BUT* you give them information, you know information is power, and they can do with it whatever they see fit. They don't need to change their schedule, they don't need to care about a distribution at all, but you give them an (hopefully) easy to understand and remember schedule *in case* they want to take it into account. On a different message Julien Blache states that The freeze date for the past few releases has always been known in advance and refined as we went but that's only true for Debian users and developers and even then not for any Debian user but only those really interested on the march of the distribution. On the other hand, I know Ubuntu produces new versions each six months about april/october or OpenBSD more or less the same and I don't even use them. I never went to the Olympic Games and still I know they are every four years starting from 00, but I'm Catholic and I don't know the dates of next year's Holy Passion but that it will be about mid spring (I put this examples because they both are time-tied but while Olympics follow an easy rule, Holy Passion follows a convoluted one), see the trend? -- 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
Hi, Jan: On Wednesday 05 August 2009 21:53:20 Jan Hauke Rahm wrote: [...] 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? Remember this is basically a meritocracy and that open sourced software tends to grow like a snowball down a hill: the first to do something seen as useful on a less than stinky way will attract attention and activity around him. Even know it's working just that way: why is it Shuttleworth now gossiping about time-based releases but because he believes on its value, probably based on ideas developed out of the fact of Ubuntu working -and working well, at least on his eyes, that way? That's why I said something in the lines of don't worry about Red Hat, SUSE, whatever... if you go and do it, you'll show it's possible and if it's useful others will jump onto your backseat in due time... and if it ends up not being so useful/good idea, well... hours and hours wasted on comitees to reach consensus won't make it any better anyway. -- 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
Steve McIntyre wrote: To be fair, I've not been doing a good enough job of talking with the project as a whole lately. I *have* been talking to a lot of people inside and outside Debian about things in that time, but a combination of a very busy day job and a new girlfriend have been keeping me much quieter than I was planning for. If you want to be fair, you should mention that you have a 2IC for exactly the too busy in real life reason. Regards, Faidon -- 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
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.) Mraw, KiBi. signature.asc Description: Digital signature
Re: On cadence and collaboration
Hi, Mark: On Wednesday 05 August 2009 23:28:19 Mark Shuttleworth wrote: [...] 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. I don't think too many conversations are needed to reach such a conclusion but plain common sense: Red Hat is the big guy in this yard and it's a for-profit company (just like Canonical) so, at least in the short run, it benefits from their bussiness enemies (like SUSE or Canonical) to stay divided and flakey. Only in the case that their competitors make a deal that can put in danger their lidership they'll contemplate going into the fest if only to leverage the field. On the other hand Canonical it's obviously the company that benefits the most with such maneouvre (not saying this is a good or bad thing 'per se': bussiness are there for the profit and in this specific case I'm inclined to think that, properly managed, Canonical's benefit is quite aligned with Debian's and even the Linux user comunity as a whole one). On the other hand and being quite cynical, if it would happen the freeze at a time among Red Hat, SUSE and Canonical, being all of them for profit, this would be a very unstable equilibrium since they all would be very pushed into cheating to their own advantage (hey! you released one week earlier... yes, but you launched your press release two weeks in advance! etc.) -- 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
Mark Shuttleworth wrote: ...snip... 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 Since you used quotation marks, this suggests you are referencing the verbatim words of an individual. I am curious about this quote. Was it a Debian Developer who said this? I find it hard to believe a fellow DD would propose such a shallow view. Your points in this paragraph should enjoy consensus within both the Debian and Ubuntu spheres of influence. A healthy ecosystem will benefit both of us. Richard -- 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
Hi, Julien: On Wednesday 05 August 2009 22:09:04 Julien BLACHE wrote: Jesús M. Navarro jesus.nava...@undominio.net wrote: [...] Why? I really don't see your point unless you mean for the packager under current conditions where no real branches are allowed on Debian (but the That's exactly my point. We suck at freezing. The problem is not we suck at freezing. Quite on the contrary I think Debian developers, the release team, the debian-installer team... all of them have done a really *amazing* work in the past, and I can say this without being suspected being just a mere user myself. The problem is that there's no non-sucking way to freeze the vast amount of packages and archs managed by Debian as a monolithic single entity. In the early days of Debian, the lesser number of packages and archs made (barely) possible the monolithic freeze. When people where overhauled (I think I remember it by the slink-potato or maybe potato-woody days) new tools pushed forward the frontier (and due to this package and arch numbers skyrocketeed), then the woody-sarge days again exposed the problem. The monolithic freeze is the simplest way both technically and from perception but maybe it's time to look for less straigthforward but more powerful ways to deal with the engineering challenges a project like Debian rises. It all boils down to the current testing system being inadapted to our needs. But that's something we couldn't really know for sure until we had tried it for a couple of releases, and I think we still won't know for a release or two because of the new tools that have been put in place to handle transitions (and others). They might help but only on a diminishing returns way: it is the management itself (the monolithic freeze concept) the one that is being stretched past its natural bounds (where complexity tends to grow exponentially as the number of packages/archs -and DDs! grow just linearly). A lot of things need to line up for a release. Debian is very large and the windows of opportunity are few and small. True. But that adds more value to the cartesian divide and conquer idea for problem approaching. This, of course, wouldn't be without its own share of problems, but they would probably be less weigthening (instead of a release being done three years from the last one as is to-date the worse case scenario with current methods, you would have a less than glamorous but decently actualized release on time due to the shiny changes not being in time to be on board -but they'll have a new chance on next release). Deciding on versions of core packages between distributions could help, but a fixed-date freeze probably won't. It could even make things worse, as it could make it harder to iron out the issues (like having to convince the release team to let a new upstream in to fix something because there's really no better way). You forget that on a branched dependency path it would be quite difficult for something really nasty reaching testing (for a conceptually similar approach see FreeBSD backports from CURRENT to STABLE; No: CURRENT-STABLE-RELEASE is not the same as Unstable-Testing-Stable although it might seem at first glance) and, of course, everything (but death) can have its (rare) exceptions. Seriously, everybody gets bored and fed up during a freeze. Not because of the freeze itself but because it takes so long. Again, i.e. FreeBSD devels don't feel that pain and they still manage to produce quite robust releases. I am of the opinion that no matter how hard you try, you can't *make* a Debian release happen. I never thought about it that way but I think you marked the bull-eye. I think to remember something Schopenhauer said once about intuitions. And then, following Schopenhauer on this, although you cannot make it happen you still can make it easier for it to happen. There's some point at which the release starts to happen, a point where a critical mass of DDs is reached, the point where everybody uses the word release more than any other word. All of which have some very real technical grounds and a heavy psycological nature too. Just the fact of being seriously comitted to a time-based release instead of current we aim towards this or that date that nobody takes really seriously but as a wishful grosstimate would heavily help for the critical DD mass and the going for the release attitude to happen. to push it to a latter date in order to have time for the tools to be developed (hey, Mr. Canonical, there you have a very interesting case where your hands and moneys would certainly be more than welcome). Remember dunc-tank? Yes, but I don't think it as a demonstration that money can't really help (or can just really help that much) but as a misguided and mistimed attempt doomed to fail. What we'd need is some sort of upstream academy where we could teach upstream: - how to version
Re: On cadence and collaboration
[Pierre Habouzit] It yields a really costly entry point to target Linux as a platform, and it's exactly why most Software Vendors target RHEL and not Linux. And that's part of the reason[1] why most of our customers are using RHELs: software vendors only certify their stuff for RHEL, because it's the established reference in the field, and that it costs too much to certify you stuff for yet-another-distro. Ahhh, so you're trying to reinvent the LSB. You could have said so earlier, it would've saved some time. -- 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
Pierre Habouzit madco...@madism.org wrote: Hi, Quoting out of context and generalizing from there, way to go. In the free software world, the diversity we have today, which is partly due to unaligned releases from the major vendors, is an asset. Security-wise ? Let's admit that, I don't want to fight on that point, even if I think it's not as simple. It does help, but sure it's not that simple either. But speaking from my experience as an employee of a software editor, I can tell that the distribution diversity is a huge problem when it comes to distributing our work. If your client use a Ubuntu LTS, a RHEL, a SuSE or worst for some, some kind of home-brewed monster taken half from a RHEL and custom packages (*sigh*) then you have as many builds to do, regress-test and so on. When you target Windows or Solaris or MacosX, Guess what: this will still be the case even with aligned releases or whatever. You won't get rid of that unless all the distros collapse into a single one overnight. JB. -- Julien BLACHE jbla...@debian.org | Debian, because code matters more Debian GNU/Linux Developer| http://www.debian.org Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- 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
Peter Samuelson pe...@p12n.org wrote: Hi, I still don't understand what is supposed to be new about the time-based freezes. The Release Team was giving us projected freeze dates all through the lenny release. For example, Same here. Either things are evolving and the proposal is being down-moded, or it was badly worded or reported initially. And I concur with your LSB comment, too. JB. -- Julien BLACHE - Debian GNU/Linux Developer - jbla...@debian.org Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
