Re: On cadence and collaboration
also sprach Andre Felipe Machado andremach...@techforce.com.br [2009.08.16.1915 +0200]: After this first round trip, the whole process would be evaluated and adjusted. Maybe cancelled or broadned. But without trying with a small group of highly user visible packages, we will not know. I agree very much with your proposed suggestion: before Debian can commit/agree to any cadence, we need to get a trial of the benefits for us, if we are to deviate from the way we (used to) do things: resources to get our release into shape, and resources to maintain our software post-release. Mr. Shuttleworth is a business man and will likely perceive the value proposition and benefits for Canonical business model in the long run, despite requiring some more commitment of resources ahead and after release, but limited to a small group of key packages that causes lots of bug reports and or binary incompatibilities during release life cycle. Not having to deal alone with these versions' bugs will reduce Canonical costs. And neither Debian alone. [0] Exactly. His suggestion bears benefits for Canonical, but in the business world, return follows investment, not the other way. At Debian Project side, there could be benefits of more skilled contributions and BTS reports and patches, with consolidated collaboration even synergetic in future, and predictable work oportunity windows for Teams. Plans could be articulated with more teams. I wouldn't go as far as speaking of more skilled contributions, as that would discount quite a lot of Debian contributors, but there are certainly opportunities in this for us. -- .''`. 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 one should never trust a woman who tells her real age. if she tells that, she will tell anything. -- oscar wilde digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Re: On cadence and collaboration
2009/8/16 Andre Felipe Machado andremach...@techforce.com.br: - Given that Debian Project has around 2000 commited devs and last I checked, that number was about 400 DD's who were actually active [0] ([Off Topic and not deserving answer as it is an unqualified suggestion]: Maybe, Canonical could be improve margins if Ubuntu becomes, ACTUALLY, a debian pure blend, differentiating itself with package preconfigurations (preseed) and package sets, and even release dates because pure-blends could release cuts of sid or testing, afaik). Maintaining a distro alone is a costly proposition. But it may not be feasible anymore. Maybe, with improving working collaboration, Ubuntu could come back to be _fully_ Debian source code progressively.) Now the CUT thing is actually something exciting, hard-to-do as it is. -- my place on the web: floss-and-misc.blogspot.com -- 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
Hello, Please, forgive my limited english language skill. I hope clarify the subject a bit more. By no means I intended to discount Debian contributors, but to ADD more skilled people from the Canonical team to Debian efforts. There is (still) a limited supply of skilled people around the world on FOSS, and grouping more of them at same tasks will (likely) improve results and reduce individual efforts, and time to accomplish things. Canonical has its own view of what should be a distribution, and (likely) will keep its way of distro shape, but some convergent efforts for mutual benefit could be reached. The proposal is not an all or nothing approach. It is a fully adjustable one. From one package to entire repository. Trying small number of relevant packages at first round, and carefully evaluating efforts and commitment, and adjusting workflow until a working one could be agreed, could get good results with minimal risk for both projects. Some Debian Teams will not take part of the experiment because they have release goals unfeasible at such reduced time frame (even with more 3 months). Also, the releases will not be equal, because many packages will not be part of the experiment, and , say, number of acceptable release RC bugs for each project are different. But releasing same base versions (at least) will ease collaborative patching after freeze AND after respective releases. Continuous evaluation and adjustment are key factors for the future of the cadence and collaboration. Commitment of both sides to accomplish results for MUTUAL benefit in the long run (even without knowing how to do this with details at starting, so the adjustments and small group of packages) is important. Any action perceived as a trick would be seriously detrimental. Clear directions and collective planning at mailing list (a new dedicated one, maybe utnubu [0]), mutual good will at this experiment and benefit of doubt: ask details before reaction in case of any attrition will help. Regards. Andre Felipe Machado [0] http://lists.alioth.debian.org/mailman/listinfo/utnubu-discuss I wouldn't go as far as speaking of more skilled contributions, as that would discount quite a lot of Debian contributors, but there are certainly opportunities in this for us.
Re: On cadence and collaboration
also sprach Andre Felipe Machado andremach...@techforce.com.br [2009.08.17.1457 +0200]: Please, forgive my limited english language skill. I hope clarify the subject a bit more. By no means I intended to discount Debian contributors, but to ADD more skilled people from the Canonical team to Debian efforts. I think the problem was not your English, but my perception error. Thanks for clarifying. I now agree. -- .''`. 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 women become like their mothers. that is their tragedy. no man does. that's his. -- oscar wilde digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Re: On cadence and collaboration
Hello, Having read all thread, and letting some time to calm down the subject, I would like to suggest a few points, presuming that synchronizing could be done in a way in benefit of both projects. (please, forgive my poor english skill, if you have doubts, please ask for detailment). - Given that Debian Project has around 2000 commited devs and contributors, and Ubuntu around 156 (please, correct and update all numbers), and that Canonical has resources to commit deadlines for some tasks, Canonical needs Debian for its business model and Debian wants skilled commited devs and contributors and useful larger user base bug reports (and patches) for same versions. - Given that Debian has more than 25000 packages and Ubuntu LTS server around 800 and desktop around 2000 (please, correct and update numbers), a basic synchronization could be tried. - Maybe, as already suggested, the first try could has a 3 month delay to be feasible. - Maybe, the first try could be version sync for a small (or even *very small*) group of high profile user visible packages that also cause large number of bug reports and or (binary?) package compatibility problems (Ex.: kernel, gcc, postgresql, mysql, apache, php, gnome and or kde, etc). - For such an agreed small group of packages, Debian Project could list teams needing help to accomplish deadlines and Canonical could commit *enough resources* to help these teams meet freeze deadlines. - The work would be performed at Debian infrastructure (the upstream) not Launchpad, and compliant with Debian quality procedures and criteria. - The commitment and quality of Canonical efforts and resources contributions could be evaluated for future steps to a broad collaboration. - All efforts should be directed to diverge the respective distro patches for the agreed set of packages to an actual minimum, ideally, zero code difference. Kernel could be a special case, but having the *same upstream version as base* will be a good thing. - After the version freeze period, the release date would be each project decision. But versions would be definitive (at least until some tragic RC bug is found) for the package subset agreed. - The respective release dates will be different, given the different requirements and pre-conditions (more platforms, # of acceptable RC bugs, different number of packages released, etc ). - Canonical *WILL* release Ubuntu LTS server and LTS desktop with such agreed group of package *versions*. Period. - After the freeze and continuing after release, Canonical will commit the resources for help cleaning the bugs, and keeping security, that get into BTS and forward relevant Launchpad reports - and patches- to BTS as soon as possible. - Again, the commitment and quality of Canonical efforts and resources contributions at this phase could be evaluated for future steps to a broad collaboration. After this first round trip, the whole process would be evaluated and adjusted. Maybe cancelled or broadned. But without trying with a small group of highly user visible packages, we will not know. Mr. Shuttleworth is a business man and will likely perceive the value proposition and benefits for Canonical business model in the long run, despite requiring some more commitment of resources ahead and after release, but limited to a small group of key packages that causes lots of bug reports and or binary incompatibilities during release life cycle. Not having to deal alone with these versions' bugs will reduce Canonical costs. And neither Debian alone. [0] At Debian Project side, there could be benefits of more skilled contributions and BTS reports and patches, with consolidated collaboration even synergetic in future, and predictable work oportunity windows for Teams. Plans could be articulated with more teams. Starting with a small group of key packages has chance to succeed and will not have too much risk for both projects. Both projects will have to concede some next release goals to reduce scope and needed work. Maybe some Debian release goal could be accomplished in a longer time frime but involved packages will NOT be part of the small group of agreed packages for FREEZE date. Thus, Debian will release with such planned goal, but the involved packages will not be the same of Ubuntu LTS, not being part of the agreed group, but without much fuss because respective Teams were not commited to release without such goal. Improvements and corrections for these suggestions are welcome. Regards. Andre Felipe Machado [0] ([Off Topic and not deserving answer as it is an unqualified suggestion]: Maybe, Canonical could be improve margins if Ubuntu becomes, ACTUALLY, a debian pure blend, differentiating itself with package preconfigurations (preseed) and package sets, and even release dates because pure-blends could release cuts of sid or testing, afaik). Maintaining a distro alone is a costly proposition. But it may not be feasible anymore. Maybe, with improving working
Re: On cadence and collaboration
Gunnar Wolf wrote: Of course, many upstreams will not accept this, as it breaks their workflow and might just feel outside influence from people they don't care too much about (and I'm not meaning the Linux desktops, as they obviously care about Linux distributions, but mainly OS-agnostic projects). Still, I think it would be worth a try. This is a good point. We do already see lots of upstreams moving to a cadence, which is improving their release energy and practices. There is *some* alignment between various upstreams, but at this stage it will take getting two or more distributions together in order to create a real center of gravity. Mark
Re: On cadence and collaboration
I admit that i m no developer who has a strong word in a debate. i m just an average joe end user who just wish that opensource software becomes better. if opensource wins, it would be a win for the community. an evidence that even in this world filled with walls, men can still cooperate breaking all barriers to create something which rivals even the closed n boxed ones. mozilla has shown how we can build something which is in every way better than the closed ones by effective collaboration. if we all come together we could create another great brand called linux. n we can win. a win for all the community. just think what we would be able to achieve if all the developers in various distros came together. i really really wish that all will come together to collaborate setting aside all the differences. n i really wish to see a better world. n thank u mark for taking this initiative.. Yahoo! recommends that you upgrade to the new and safer Internet Explorer 8. http://downloads.yahoo.com/in/internetexplorer/
Re: On cadence and collaboration
Vipin Mathew dijo [Thu, Aug 13, 2009 at 08:24:21AM -0700]: mozilla has shown how we can build something which is in every way better than the closed ones by effective collaboration. if we all come together we could create another great brand called linux. n we can win. a win for all the community. just think what we would be able to achieve if all the developers in various distros came together. [OT] Some people (me not included, I refuse to even try it) will point out that it has beaten the pants out of MSIE, but propietary browsers such as Opera or Safari are way ahead. There was a (short) thread recently on d-devel where even some Debian Developers (of course, everybody is free to use what they prefer!) say they prefer Opera over any Mozilla derivative. But anyway, please don't reply to this, it is not needed. Just raising the point that Mozilla might not be the best example after all. And don't get me started on OpenOffice! ;-) -- Gunnar Wolf • gw...@gwolf.org • (+52-55)5623-0154 / 1451-2244 -- 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
Manoj Srivastava dijo [Wed, Aug 05, 2009 at 10:08:13AM -0500]: 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. Umm... But the time from freeze until release is so far not predictable at all. Etch was way swifter than Lenny (or FFS than Sarge). They were all intended to be frozen for much less time than they ended up being. So… Freezing every 24 months (I won't even make a pun on your 24 years) can push us over the edge. Yes, I understand that this means the 24 months include the freeze time for the previous release. Still. -- Gunnar Wolf • gw...@gwolf.org • (+52-55)5623-0154 / 1451-2244 -- 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, No, not quoting a bit. And answering to the top of the thread. Over a week old, also. And even more, not having read a majority of the replies. Still. Mark, I think you are personally among the best positioned people to be heard on this topic - And your goal is quite worthy. However, I think pushing the distributions to freeze semi-coordinatedly (as much coordinatedly as possible) is not the best way. As you have witnessed with Debian, some people will grill you at full flame. RH didn't pay much attention. I'd suggest you to try approaching from the other side, although it will surely prove a very hard path as well: If we say now, «All distributions should freeze in December», many groups in each will cry because it breaks their plans. Because their upstreams are working full-steam (and are either at the most unstable point in their release cycle or because they are in mid-freeze). I have been bitten by this before (i.e. by the not-precisely-2.0 mod_perl that was shipped in Sarge, breaking source compatibility with any other mod_perl in the face of Earth, which in turn made me miserable when having a development machine running Sid), and will quite probably be bitten again (i.e. the Ruby interpreter crew worked on and announced how their upstream version management scheme will be handled, and we will probably soon have to rush on a binary package recreation/renaming frenzy soon). Some things will/would be probably left out (i.e. the officially useful Perl 6.0 release). Anyway - I think that a key for having distributions agree to a coordinated freeze is to have upstream development also feel and adhere to this cadence. If upstreams try to stabilize towards mid-even-years (i.e. July 2009, July 2011, …), we distributors will have a much easier time integrating them. And your idea will have a much better shot at being accepted. Of course, many upstreams will not accept this, as it breaks their workflow and might just feel outside influence from people they don't care too much about (and I'm not meaning the Linux desktops, as they obviously care about Linux distributions, but mainly OS-agnostic projects). Still, I think it would be worth a try. Greetings, -- Gunnar Wolf • gw...@gwolf.org • (+52-55)5623-0154 / 1451-2244 pgpIHVAx41dUr.pgp Description: PGP signature
Re: On cadence and collaboration
On Wed, Aug 12 2009, Gunnar Wolf wrote: Manoj Srivastava dijo [Wed, Aug 05, 2009 at 10:08:13AM -0500]: 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. Umm... But the time from freeze until release is so far not predictable at all. Etch was way swifter than Lenny (or FFS than Sarge). They were all intended to be frozen for much less time than they ended up being. So… Freezing every 24 months (I won't even make a pun on your 24 years) can push us over the edge. Yes, I understand that this means the 24 months include the freeze time for the previous release. Still. In the time line below, I am considering freeze of the toolchain and base (d-i) as the start of the freeze, since we have not yet done that for Squeeze). These are culled from the d-d-a archive, looking for the mail announcing thte tool chain freeze. sarge: 2004/08 - 2005/06 (10) (freeze in stages) etch:2006/08 - 2007/04 (5) 24 months between freezes, 22 for release lenny: 2008/07 - 2009/02 (7) 21 months between freezes, 22 for release squeeze: 2010/?? - This is different from the time line AJ posted, since I am counting from the time we froze toolchain/base packages, since as far as I know the tool chain freeze date has not been announced. So it seems to me that we have pretty much stable interfreeze and ihnter-release cycles, and which is why I think we can manage to sustain 2 year release cycles. manoj -- You will lose an important disk file. 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
Re: On cadence and collaboration
Le mardi 11 août 2009 à 02:48 +0300, Martin-Éric Racine a écrit : 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. I think that this point truly deserves to be discussed for a number of reasons. Personally, I think that releasing a new distribution right after GNOME or KDE has produced a new major version is an extremely bad idea, because the X.XX.0 release of anything tends to have too many rough edges (feature regressions, out of sync translations, etc.) that usually need further polishing via X.XX.1 and X.XX.2 releases before a new major desktop release becomes truly usable by non-technical people i.e. not requiring any workaround for some stupid regression that gets fixed later in point releases, much after the initial distribution release has started shipping with X.XX.0. Which is precisely why, during freezes, the release team lets migrate minor releases for GNOME packages, based on the strict policies upstream adopts during stable cycles. -- .''`. 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
On Wed, 5 Aug 2009 10:26:07 -0300, Marga wrote: 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. 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. I think that this point truly deserves to be discussed for a number of reasons. Personally, I think that releasing a new distribution right after GNOME or KDE has produced a new major version is an extremely bad idea, because the X.XX.0 release of anything tends to have too many rough edges (feature regressions, out of sync translations, etc.) that usually need further polishing via X.XX.1 and X.XX.2 releases before a new major desktop release becomes truly usable by non-technical people i.e. not requiring any workaround for some stupid regression that gets fixed later in point releases, much after the initial distribution release has started shipping with X.XX.0. As such, I'd prefer if whatever common freeze for core packages that is agreed between Debian and its derivatives (Ubuntu and others) only happened after the next X.XX.2 versions of GNOME and KDE have been released. This will of course require GNOME and KDE to sync their clocks as well and my understanding is that recent Guadecs and aKademies have seen the two communities visiting each other and working towards this goal, which is very good news indeed. Some people might also find ensuring that XFCE and LXDE are also kept in the loop is desirable too and, if that's the case, it would be desirable to help them achieve this goal as well. I think that the fact we're having this discussion and are taking concrete actions towards achieving cadence is a step in the right direction. I'd however humbly hope that distributions would be as willing to accommodate upstream cycles as they hope to see upstream accommodate distribution cycles. Both sides will have to give some slack and agree to shift their release cycles by a couple of months and meet half-way, for this cadencing idea to work. One simply cannot expect upstream to magically jump just because one or two major distributions reached a consensus. The same way that Mark suggested Ubuntu lending resources to help Debian reach the target freeze on time, resources will need to be lent to upstream to reach the same target date on time. Best Regards, Martin-Éric -- 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 Thu, Aug 6, 2009 at 10:25 PM, Matthias Andreematthias.and...@gmx.de wrote: i. if you can't deal with a bug, tell somebody who can. Leaving it to rot is going to drive users away. Leaving bugs to rot happens everywhere, in various upstreams, in Debian, Ubuntu, Fedora and probably other distributions. There just are not enough free software developers in existence to perform all of the needed maintenance on each and every free software project in existence. ii. make package owners explicit. Just assigning package responsibilities for all packages to some opaque mailing list evidently does not work. The list gets my upstream maintainer updates to the bug, yet nobody cares. IIRC Ubuntu universe specifically works the opposite way and I'm unsure if Ubuntu have enough universe developers to change this. I'm not going to ferret up all possible downstreams. One tool that makes that easier is 'whohas': http://www.philippwesche.org/200811/whohas/intro.html I've personally used it with both upstream and Debian hats on and was very happy to find that it exists. -- bye, pabs http://wiki.debian.org/PaulWise -- 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
Michael Banck wrote: On Fri, Aug 07, 2009 at 10:55:36AM +0200, Julien Cristau wrote: On Fri, Aug 7, 2009 at 10:38:56 +0200, Bernd Zeimetz wrote: How does Ubuntu want to do a proper (commercial) support for their packages if they don't even have the time/manpower to take care of their bugs? Taking care of bugs is something that should be done properly in every distribution. You can look at bugs filed by paying customers, and ignore the rest. Really, I don't think discussing Canonical's business model and/or Ubuntu/Canonical's approach to QA/bug triaging/bug fixing has to be discussed here. As long as it is (partly?) based on the fact that bugs will be fixed by Debian for free so Ubuntu can just reuse the bugfixes and get the money for them, I think it should be discussed. There is nothing bad in general with that as long as Ubuntu gives their bugfixes back to Debian and we don't have to retrieve them out of a mess of Ubuntu patches... -- 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
Sandro Tosi wrote: what can happen is that he prepare a rough solution, sent to debian in a sense hey, take it, I've done my work, it's an ugly hack but I have no time to prepare an elegant solution; Now I got to go, I have another 1000 things to do. I'm not sure it will happen, but I fear it would. That happens already. See the Python 2.6 migration for a lot of bad examples... -- 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
Bernd Zeimetz wrote: Sandro Tosi wrote: what can happen is that he prepare a rough solution, sent to debian in a sense hey, take it, I've done my work, it's an ugly hack but I have no time to prepare an elegant solution; Now I got to go, I have another 1000 things to do. I'm not sure it will happen, but I fear it would. That happens already. See the Python 2.6 migration for a lot of bad examples... Hmm, AFAICT python2.6 did not really happen in Debian yet because Mathias is trying to not continue with the existing hacks that have major issues when upgrading and wants to have a clean solution. AFAICS that was already communicated in February [0] and was only really acted on around DebConf [1]. You can blame everyone involved, but I think it might be better to cooperate on fixing it instead. Cheers Luk [0] http://lists.debian.org/debian-devel/2009/02/msg00431.html [1] http://lists.debian.org/debian-python/2009/08/msg3.html -- 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
Luk Claes wrote: Bernd Zeimetz wrote: Sandro Tosi wrote: what can happen is that he prepare a rough solution, sent to debian in a sense hey, take it, I've done my work, it's an ugly hack but I have no time to prepare an elegant solution; Now I got to go, I have another 1000 things to do. I'm not sure it will happen, but I fear it would. That happens already. See the Python 2.6 migration for a lot of bad examples... Hmm, AFAICT python2.6 did not really happen in Debian yet because I'm not talking about Debian, but about the Python 2.6 transition in Ubuntu. -- 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
The Python mess in Debian (was: Re: On cadence and collaboration)
To come back to Debian Luk Claes wrote: Hmm, AFAICT python2.6 did not really happen in Debian yet because Mathias is trying to not continue with the existing hacks that have major issues when upgrading and wants to have a clean solution. The only hack is the broken piece of python-central and Matthias not being able to accept that somebody else is able to provide a well working solution without a ton of hacks which makes it a pain in the ass to migrate away from it. We now have a *lot* of packages with extra maintainer scripts which take care of cleaning up behind python-central. That's not the way ho things should work. AFAICS that was already communicated in February [0] and was only really acted on around DebConf [1]. Wrong. Several people tried to contact Matthias on various ways and never got a reply. He also completely failed to communicate with those people who maintain most Python related packages on Debian, except during Debconf. This is *NOT* the way how Python should be maintained. Actually several people already thought abut hijacking Python due to the complete lack of communication with the Python Maintainer, who prefers to force his changes on people instead of finding an acceptable resolution. While I think that large parts of this are the result of him being overworked due to Ubuntu stuff, this is not the way how things should go. During Debconf [1] came up, but I can't see it happen soon as there are *way* too many problems with the proposal, and it would bring us back to pre-Etch areas.. There were rumours that Python 2.6 was not uploaded to unstable due to bugs or missing things in python-support, but as usual there was no bug filed, and nobody talked to the python-support maintainer. You can blame everyone involved, but I think it might be better to cooperate on fixing it instead. Don't even think about blaming me for not trying to cooperate on Python related things if you have no damn clue. [0] http://lists.debian.org/debian-devel/2009/02/msg00431.html [1] http://lists.debian.org/debian-python/2009/08/msg3.html Cheers, Bernd -- 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: The Python mess in Debian (was: Re: On cadence and collaboration)
On 2009-08-08, Bernd Zeimetz be...@bzed.de wrote: Wrong. Several people tried to contact Matthias on various ways and never got a reply. He also completely failed to communicate with those people who maintain most Python related packages on Debian, except during Debconf. This is *NOT* the way how Python should be maintained. Actually several people already thought abut hijacking Python due to the complete lack of communication with the Python Maintainer, who prefers to force his changes on people instead of finding an acceptable resolution. While I think that large parts of this are the result of him being overworked due to Ubuntu stuff, this is not the way how things should go. During Debconf [1] came up, but I can't see it happen soon as there are *way* too many problems with the proposal, and it would bring us back to pre-Etch areas.. There were rumours that Python 2.6 was not uploaded to unstable due to bugs or missing things in python-support, but as usual there was no bug filed, and nobody talked to the python-support maintainer. I think there were at least two things (I think not check them, but from memory what Matthias told me): * python-support breaks upstream assumptions about relative imports. * python-support does not always have stable symlink handling, i.e. they should maybe be shipped by the package instead. (I'm relatively unsure about this though, as I don't recall the program; but I think it also has to do with the fact that you sometimes need to call update-python- modules from maintainer script.) It might be true however that most of the issues he has left did not manifest themselves in bug reports, probably because the personal relationship of the two maintainers misses some trust and needs a neutral party to communicate it. Matthias also stated during UDS that he wouldn't mind python-central to be dropped when some remaining issues in python-support are fixed (at the very least the first point above). I don't know if Debconf changed something in this regard. Anyway I don't know how responsive he is wrt emails. I can understand that the hostility on d-python didn't help in that regard, but maybe To'ing or Cc'ing him on some mails might help. Kind regards, Philipp Kern -- 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
Bernd Zeimetz be...@bzed.de writes: As long as it is (partly?) based on the fact that bugs will be fixed by Debian for free so Ubuntu can just reuse the bugfixes and get the money for them, I think it should be discussed. People keep saying things like this, but no one I know who's running Ubuntu is paying for it. Clearly Canonical does have a business model and is charging for some things, but are they making money off of *our bug fixes*? That's not clear to me at all. Personally, I view Ubuntu users as just a larger audience for the same packages I'm making for Debian. If something specific to Ubuntu breaks a package, well, Ubuntu gets to keep both pieces unless it's fairly obvious to me what's wrong. But insofar as those users find problems that affect the package in general, it's just more input to make it better for everyone. (Also, separately, I came to terms with people making money off of my work without necessarily giving anything back a long time ago. I think that's just part of free software.) There is nothing bad in general with that as long as Ubuntu gives their bugfixes back to Debian and we don't have to retrieve them out of a mess of Ubuntu patches... This can be a major problem for some packages, but I have to say, I think that's way overstated for most things. For example, I've never had much trouble extracting relevant fixes from Ubuntu patches for my packages. -- 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
Michael Bienia wrote: I'm sorry about this but the amount of bugs flowing in into Ubuntu is bigger that can be handled by the available man power, being it developer or community members. How does Ubuntu want to do a proper (commercial) support for their packages if they don't even have the time/manpower to take care of their bugs? Taking care of bugs is something that should be done properly in every distribution. -- 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
Luk Claes wrote: If the freeze date is well known in advance the question becomes moot unless some maintainer wants to work against the freeze AFAICS. Having a known freeze date is meant to help everyone to be able to plan better and refrain from doing high impact changes right before the freeze. There is nothing bad with a fixed freeze date. Just with the way it was planned for December. -- 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 Fri, Aug 7, 2009 at 10:38:56 +0200, Bernd Zeimetz wrote: Michael Bienia wrote: I'm sorry about this but the amount of bugs flowing in into Ubuntu is bigger that can be handled by the available man power, being it developer or community members. How does Ubuntu want to do a proper (commercial) support for their packages if they don't even have the time/manpower to take care of their bugs? Taking care of bugs is something that should be done properly in every distribution. You can look at bugs filed by paying customers, and ignore the rest. Cheers, Julien -- 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
Cyril Brulebois wrote: Raphael Geissert geiss...@debian.org (05/08/2009): Like some people said during Debconf: freezing in December doesn't necessarily mean freezing the first day or even the first week of December; the 31 is still December, which means there are 30 days to decide many things, if necessary. Without having to resort to nitpicking on days, was the “freeze” term define anywhere? My main question would be: will it be possible to e.g. switch the default compiler right before the freeze and trigger possible hundreds of serious FTBFS bugs? Or is some incremental freeze still supposed to happen? (Putting -release in Cc to catch their attention.) At least on the Ubuntu side, there would be room to agree in advance on items that are as yet unreleased, but which have for various reasons clear advantages and well understood risks. So, for example, if someone on the toolchain team said GCC 4.5 is going to be released in February, and we've run a test rebuild of the archive and there were only 20 FTBFS's then it might well be possible to get consensus around that new version being planned as a consensus base version for releases in 2010. Mark -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: On cadence and collaboration
On Fri, Aug 07, 2009 at 10:55:36AM +0200, Julien Cristau wrote: On Fri, Aug 7, 2009 at 10:38:56 +0200, Bernd Zeimetz wrote: How does Ubuntu want to do a proper (commercial) support for their packages if they don't even have the time/manpower to take care of their bugs? Taking care of bugs is something that should be done properly in every distribution. You can look at bugs filed by paying customers, and ignore the rest. Really, I don't think discussing Canonical's business model and/or Ubuntu/Canonical's approach to QA/bug triaging/bug fixing has to be discussed here. Michael -- 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
Bernd Zeimetz wrote: Luk Claes wrote: If the freeze date is well known in advance the question becomes moot unless some maintainer wants to work against the freeze AFAICS. Having a known freeze date is meant to help everyone to be able to plan better and refrain from doing high impact changes right before the freeze. There is nothing bad with a fixed freeze date. Just with the way it was planned for December. s/planned/announced/ It was and still is not meant as a decision, but as a proposal though the announcement said otherwise due to miscommunication from my side which I cannot undo unfortunately. I'm not convinced that we will be able to freeze in December anymore and I still want to talk to teams and people to see how their schedules can fit in with a proposal of a new freeze date. I do consider that we should delay the date significantly as many of the feedback already received indicates that there is more time needed before we freeze. Cheers Luk -- 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 wrote: Cyril Brulebois wrote: Raphael Geissert geiss...@debian.org (05/08/2009): Like some people said during Debconf: freezing in December doesn't necessarily mean freezing the first day or even the first week of December; the 31 is still December, which means there are 30 days to decide many things, if necessary. Without having to resort to nitpicking on days, was the “freeze” term define anywhere? My main question would be: will it be possible to e.g. switch the default compiler right before the freeze and trigger possible hundreds of serious FTBFS bugs? Or is some incremental freeze still supposed to happen? (Putting -release in Cc to catch their attention.) At least on the Ubuntu side, there would be room to agree in advance on items that are as yet unreleased, but which have for various reasons clear advantages and well understood risks. Just providing a bit of Debian specific context: A freeze in Debian is usually very strict and only allows small diffs that fix release critical bugs, release goal bugs (and sometimes documentation or translation bugs). So, for example, if someone on the toolchain team said GCC 4.5 is going to be released in February, and we've run a test rebuild of the archive and there were only 20 FTBFS's then it might well be possible to get consensus around that new version being planned as a consensus base version for releases in 2010. This is normally out of the question within a Debian freeze, just before the freeze could be an option if there is a clear commitment to fix the remaining bugs though. Cheers Luk -- 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 Fri, Aug 7, 2009 at 18:37, Luk Claesl...@debian.org wrote: It was and still is not meant as a decision, but as a proposal though the announcement said otherwise due to miscommunication from my side which I cannot undo unfortunately. I'm not convinced that we will be able to freeze in December anymore and I still want to talk to teams and people to see how their schedules can fit in with a proposal of a new freeze date. I do consider that we should delay the date significantly as many of the feedback already received indicates that there is more time needed before we freeze. I'd like to loudly thank you for admit there was a problem in how this was released to the public and for revisiting your proposed plan after feedbacks received (even if some was rather hard). This is a clear sign of the professionality you're putting in this role (and how hard it is to wear that hat). Thanks, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi -- 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 Fri, Aug 7, 2009 at 00:30, Michael Bieniamich...@bienia.de wrote: On 2009-08-06 16:25:47 +0200, Matthias Andree wrote: [I'm Ubuntu developer (MOTU to be more specific), so I might be biased] I certainly won't excuse some things that are not happening, I know that Ubuntu needs to improve in some aspects. But realising this and get things improved are still not the same. I just want to add some data which hopefully explains why things are happening or not happening. ... I'm sorry about this but the amount of bugs flowing in into Ubuntu is bigger that can be handled by the available man power, being it developer or community members. Bug #20 was filed March 2008 Bug #30 was filed Nov 2008 Bug #40 was filed Jul 2009 This is around 10 bugs per 9 months, or around 350 bugs per day. While these might include also bugs filed only on projects using Launchpad for bug tracking, the fast amount of them are filed on Ubuntu packages. While this is not really pleasant but it's happening that some bugs are not looked upon for month (or even longer). ... Unlike Debian, Ubuntu hasn't this one maintainer per package approach (don't know about other distributions). In Ubuntu whole teams are responsible for the components: core-dev for packages in main and MOTU for packages in universe and multiverse. Both approaches have there pro and con. For and a package being in main doesn't necessarily mean that it's better maintained than packages in universe (on a best effort basis). They might only be in main because they are needed by an other package in main (sorry, don't know the reason for bogofilter being in main). While Debian has over 1000 persons with upload rights, Ubuntu counts only 135 persons with upload rights (from those only 56 can upload to main). At the same time there are over 3000 source packages in main and over 12000 source packages in universe. One can easily see that this won't work to get every package the amount of care that it deserves. So in the end many packages are taken unchanged from Debian. Yet bugs don't stop getting filed in Ubuntu and need to be looked at and acted accordingly. This internal view shows how Ubuntu developers are already under-staffed; so where will the resources for collaboration be taken from? If current developers do not even have the time to look at bugs, how can they work on the collaboration tasks and at what price? for both of us: - for Ubuntu, because you have to redirect attention of a developer to another task, while he had already too many to work on; - for Debian, because we *can* (it's a possibility) receive work of low quality; consider the generic Ubuntu developer that must work (because his time was committed to it) to do a collaboration task: what can happen is that he prepare a rough solution, sent to debian in a sense hey, take it, I've done my work, it's an ugly hack but I have no time to prepare an elegant solution; Now I got to go, I have another 1000 things to do. I'm not sure it will happen, but I fear it would. How can this be solved? I used Debian just to keep the example real (and because it's the distro I care about). Regards, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi -- 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 st...@einval.com wrote: Hi, A time-based freeze could mean for some teams that they'll have to stop work basically for months to a year. Exaggeration, -1. Excuse me, what? This is exactly what happened for this past freeze, so you can take that back, kthxbye. 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
Jesús M. Navarro jesus.nava...@undominio.net wrote: Hi, That's exactly my point. We suck at freezing. The problem is not we suck at freezing. Quite on the contrary I think I should have written we suck at operating during the freeze or something alike, that was a bit of a bad shorthand :) 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. All things considered (size and nature of the project, nature of the contributions, governance model, ...) I think we're doing amazingly well. It could be a lot worse, especially given nobody has ever done that before. We're bigger than any other project, nobody has been there before us. 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. Back in the days, frozen was just that and unstable was carrying on with its life (with a bit less activity, but only a bit). Today, unstable is just as frozen as testing is during the freeze. In the end, testing kind of works to prepare a consistent set of packages that we can freeze at some point, so it's a good development tool, but it's not a good release tool. WRT unstable, testing is a step backward. 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 If you're talking of freezing/releasing different sets of packages more or less independently etc, this has been discussed to death already. You forget that on a branched dependency path it would be quite difficult for something really nasty reaching testing (for a conceptually similar approach It's not that difficult. It does happen, simply because since the testing introduction (and Ubuntu) we have less users using unstable and reporting bugs. The direct consequence is that bugs do make it to testing more than we'd like. 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. Both, actually. 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. My point exactly. You can *only* help the process. I understand just how frustrating that can be for release managers, but it's something that you need to accept to do this job. 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 Absolutely. 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. I think there's been a real push over the last years and a lot more DDs are focused on getting releases out the door now. We talk about releasing more than ever, so this cannot escape anyone nowadays. As for the cadence, the 18/24 months is something that looks like it can work repeatedly and is generally a good pace for us etc. So, in a nutshell, it's all there already, though not as formal as some would like it to be, it seems. 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. Fair enough. What we'd need is some sort of upstream academy where we could teach upstream: [...] Yes... It might be worth it some kind of best practices manual coupled with some kind of peer-review process for such practices (the equivalent to the I think something more interactive and hands on would be best. RTFM never worked that well in this case. 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
Re: On cadence and collaboration
On Wed, Aug 05, 2009 at 10:51:08PM -0500, Peter Samuelson wrote: [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. Actually not, I'm just explaining why I don't think that the Linux distributions diversity is an asset. -- 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
Mark Shuttleworth schreef: 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. Redhat/Fedora seems to be difficult to win, but is a strong partner. Maybe we could try to make a freeze with both Debian and Ubuntu on a date that RedHat freezes in the hope Redhat likes it for a next time. We can do our best to make it attractive for them. Ubuntu will maybe be the first to release. No problem for me. Important point for me to choose Debian is the security-support on all packages. And Debian stable has more time so it can learn from problems in other distributions. With regards, Paul van der Vlis. -- http://www.vandervlis.nl/ -- 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 2009-08-06, Josselin Mouette j...@debian.org wrote: And this is precisely why it was asked that for squeeze, frozen and testing remain different suites during the freeze. Currently I have no idea of whether this will happen. While I see the point of this I don't know if I would be happy. If people just continue with business as usual for unstable and testing we will not release. See the RC bug fixing activity of the last release. A short freeze just means that people would actually have to squash some bugs, but it seems that the majority of DDs simply don't care. Freezing a bit of unstable helps us to apply some peer pressure. Kudos to all of them who helped releasing in the last freezing cycle. I just don't like the perspective of feeling alone in the next one. Kind regards, Philipp Kern -- 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
Cyril Brulebois wrote: Raphael Geissert geiss...@debian.org (05/08/2009): Like some people said during Debconf: freezing in December doesn't necessarily mean freezing the first day or even the first week of December; the 31 is still December, which means there are 30 days to decide many things, if necessary. Without having to resort to nitpicking on days, was the “freeze” term define anywhere? My main question would be: will it be possible to e.g. switch the default compiler right before the freeze and trigger possible hundreds of serious FTBFS bugs? Or is some incremental freeze still supposed to happen? (Putting -release in Cc to catch their attention.) If the freeze date is well known in advance the question becomes moot unless some maintainer wants to work against the freeze AFAICS. Having a known freeze date is meant to help everyone to be able to plan better and refrain from doing high impact changes right before the freeze. Cheers Luk -- 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
Luk Claes l...@debian.org (06/08/2009): If the freeze date is well known in advance the question becomes moot unless some maintainer wants to work against the freeze AFAICS. Having a known freeze date is meant to help everyone to be able to plan better and refrain from doing high impact changes right before the freeze. We already have maintainers working against any kind of common sense. We have maintainers breaking transitions, delaying them, or starting them when they're not welcome. We even have a mechanism to enforce sanity (transition-related upload prevention/blocks). Why would/should the freeze be treated in a different manner? Mraw, Mooty KiBi. signature.asc Description: Digital signature
Re: On cadence and collaboration
On Thu, Aug 06, 2009 at 02:21:49PM +0200, Cyril Brulebois wrote: Luk Claes l...@debian.org (06/08/2009): If the freeze date is well known in advance the question becomes moot unless some maintainer wants to work against the freeze AFAICS. Having a known freeze date is meant to help everyone to be able to plan better and refrain from doing high impact changes right before the freeze. We already have maintainers working against any kind of common sense. We have maintainers breaking transitions, delaying them, or starting them when they're not welcome. We even have a mechanism to enforce sanity (transition-related upload prevention/blocks). Why would/should the freeze be treated in a different manner? There have always been, and always will be, a small subset of developers who work against our freezes out of ignorance or even hostility. For the most part, however, developers seem to be pretty good at acting in their own enlightened self-interest, and not behave in ways that are guaranteed to make the freeze longer by making it harder to release. It's hard to measure this quantitatively because you don't have a real control, but certainly my subjective experience is that this is very effective. -- 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
On Thu, Aug 06, 2009 at 02:08:26AM +0200, Cyril Brulebois wrote:
Or is some incremental freeze still supposed to happen?
During the talk/discussion at DebConf, IIRC Luk stated that
incremental freezes had a negative effect because for many developers
it was not clear what/when was going to be frozen. The logical
consequence drawn there (again, IIRC) has been that the release team
would prefer releasing all at once.
Note, however, that we have always used to have unblocks during
freezes; the policy on how unblocks are handled is completely
orthogonal to how sharply you freeze.
(Putting -release in Cc to catch their attention.)
Keeping that to ensure I'm not on crack with my memories :-)
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
Re: On cadence and collaboration
On Thu, Aug 06, 2009 at 03:18:08PM +0200, Stefano Zacchiroli wrote:
During the talk/discussion at DebConf, IIRC Luk stated that
incremental freezes had a negative effect because for many developers
it was not clear what/when was going to be frozen. The logical
consequence drawn there (again, IIRC) has been that the release team
would prefer releasing all at once.
^
Here of course I meant freezing.
.oO( is that an instance of a freudian typo ?)
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
Re: On cadence and collaboration
[Please Cc: replies back to me, I'm not on debian-proj...@] Mark, I think you have a biassed view in your role as Ubuntu maintainer. This isn't bad in itself, but it needs to be written so that positions are clear. My position is: I'm currently using openSUSE for my development, with occasional portability tests on Solaris, NetBSD, FreeBSD, Ubuntu. I'm looking after my Mom's Ubuntu installation. More importantly, I'm also an upstream maintainer of fetchmail and leafnode, and I'm also co-maintainer of bogofilter. I would not consider any of these projects large. This is not Mozilla, Adobe. Still, my upstream maintenance considers needs of users and distributors, i. e. I will usually accept bug reports for outdated versions if I know that area of the code hasn't changed. The whole longish message of yours is about telling that others need to move and how good it all could be if everbody did, and you're pulling an argument that this was in the interest of end users. This is but a pretext, Ubuntu apparently doesn't catch enough karma among developers through deeds and achievements, and your begging for compromises isn't bound to improve on that, but quite the contrary. There are some key points of criticism I'd like to mention: 1. General communication with upstream maintainers, and consequences I recently - out of curiosity - looked at the launchpad.net Ubuntu bugs for packages I (co-)maintain upstream. Upstream here is at the origin, not Debian packaging or something, list as above. Some were relevant and still current, and Ubuntu failed to either do something about the bugs (as in debug, write a patch) or at least tell people who were in a position to do something about the problem, concretely, forward the bug upstream. This is the very least you must do. Example: https://bugs.launchpad.net/ubuntu/+source/bogofilter/+bug/320829 This had sufficient information to debug, and lay around for half a year. Nobody in Ubuntu bothered to look at the report, or to forward it to the upstreams. Another observation is that Ubuntu bugs and bug changes are frequently forwarded to dozens of people, yet nobody cares to look. All you get is me too or dramatic narrations of how the bug ate somebody's dog. From maintainers, such as ubuntu core maintainers, for core packages: deafening silence. I'm happy to help distributions (without picking any particular, I don't care about your name, but about how you act), but I'm definitely not going to ferret up the downstream maintainers or their bugs. This was a one-time event. Some proposals for Ubuntu's part in this: i. if you can't deal with a bug, tell somebody who can. Leaving it to rot is going to drive users away. ii. make package owners explicit. Just assigning package responsibilities for all packages to some opaque mailing list evidently does not work. The list gets my upstream maintainer updates to the bug, yet nobody cares. iii. if you take my work (i. e. upstream tarball), and you're a downstream packager, it's your moral duty to approach me and tell me who you are and what you do. We appear to share the intention of improving user experience, but as written earlier, I'm not going to ferret up all possible downstreams. And there is prior evidence that my expectations work out: I have occasional contact with the downstream maintainers of other distributions, such as FreeBSD, NetBSD/pkgsrc, Debian, Fedora/Red Hat, OpenBSD, openSUSE. Often, new-coming packagers will approach the upstreams and introduce themselves, and perhaps share questions, bug reports or patches. I've never seen this happen for Ubuntu. Bottom line: Ubuntu has to work about something, or to contact whoever they feel fit, if they want something to change. 2. Getting innovations right, and going them all the way Ubuntu has some interesting approaches, such as Upstart. However, these are incomplete, underdocumented, and in consequence half-baked. If you care about the end user experience, you've got to bite the bullet and not only lick it. Discussing about superimposing schedules and conferences doesn't help at all. Providing half-baked solutions is a real nuisance for the end user and the upstreams: it creates the very inconsistencies that you'd like to avoid, and it adds one more item to the half-baked items list. Users get deprived of the old way of doing things (or it's a whole heap more work to do it the old way), the new way doesn't work yet, and upstreams sometimes see the fallout of such downstream changes. Across all Linux distributions, the most prominent innovations I recall are, in random order: X, X-autoconfig, Intel driver for X, dbus/HAL, NetworkManager, Pulseaudio, Upstart, KDE4 (and particularly the lack of established and crucial features therein, such as X.509 certificate management). You can't expect other distributions to collaborate if you don't muster the
Re: On cadence and collaboration
On Wed, 05 Aug 2009 10:21:38 +0100 Mark Shuttleworth m...@ubuntu.com wrote: Hi folks Hi there We're already seeing a growing trend towards cadence in free software, which I think is a wonderful move. Here, we are talking about elevating that to something that the world has never seen in proprietary software (and never will) - an entire industry collaborating. Collaboration is the primary tool we have in our battle with proprietary software, we should take the opportunities that present themselves to make that collaboration easier and more effective. Truly an enthusiastic speech which gives us a vision of a bright new world and even includes the yes we can spirit. And yet I lack the trust that such will ever happen. To convince so many and so diverse groups to all commit to a single goal, and may it just be something as profane as a common freeze date, would be unprecedented in human history. But let's assume I'm wrong, and it is actually going to happen ... 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 :-) I'm sorry then to rain on your parade. Despite the risk of being accused of heresy, let me state my doubts about such a move in general. I leave discussions about specific advantages or disadvantages that this might hold for Debian to others, much more competent on the matter. Instead I would like to approach this issue more abstractly. We know of many examples in nature, human society, economics, computing, etc., that show that distributed, non-hierarchical, self-organising system can be much more powerful than centrally controlled systems. It can be proved, for instance, that a swarm of independent units without central control can converge a solution in cases, where classical iterative schemes that have such a central control do not[0]. Add central control (a central clock) and this power vanishes. While it is not clear if such a model applies to the FLOSS world without doing extensive research, I strongly believe that it would harm the system if you add a central control (in this case some central committee that decides on freeze dates). While it might look appealing at first sight to have a central authority to decide on certain matters, this rips the system of the ability to change quickly and adapt to new circumstances. But let's again assume that I'm wrong and that it would do the FLOSS world good. But: good how? What exactly will be better? It is an ambitious goal you propose which will require projects to make compromises, to invest time and possibly money, to change their priorities. So at the end of the day people will want to know if it was worth the investment. What are the criteria on which this question can be decided? That, say, GNOME releases in time for the distributions to pick it up is easily testable, but not an advantage on its own. That the world becomes a better place is a worthwhile goal but impossible to verify. Would you please give verifiable and falsifiable criteria which can be evaluated objectively to answer such a question? Examples would be - the productive work/bug fixing ration increases - less security leaks - number of people moving to GNU/Linux per year increase - etc. At the moment it is not clear for me, what the real advantage for projects and users would be. However, I completely agree that collaboration helps everybody. But instead of inserting an additional level in the hierarchy to govern such collaborations, I believe the better approach is to tighten the collaboration-network. Here collaboration happens on a different level. Between package maintainers and their upstream, between projects that depend on each other, between Debian package maintainers and Ubuntu package maintainers, etc. Cheers, harry [0] Gerardo Beni: Order by Disordered Action in Swarms. signature.asc Description: PGP signature
Re: On cadence and collaboration
On Wed, Aug 5, 2009 at 4:44 PM, Mark Shuttleworthm...@ubuntu.com wrote: 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. Well, this is not the proposal as it was announced, and this is definitely not what we understand as freeze in Debian. In Debian, freezing in December means that no new versions enter testing after the freeze begins. I think the proposal as you word it would be fine, since this would probably mean freezing later on. Maybe March or so. This would make much more sense, from my point of view. But this is NOT what was announced and communicated to us. 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. I don't think it makes sense to rush our release as much as it's being proposed only to finish with different versions of big components. I understand that GCC and X are important, but I don't think all the hard work makes sense unless we can also sync the desktops. 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. That's not how it has worked in the past. We've had some scaled freeze, freezing the toolchain first and the rest of the packages afterwards, but it's never been some maintainer teams who decided what was frozen and what wasn't, it's always been the Release Team. And the Release Team has said that they'd rather not do the scaled freeze this time, they'd rather just do one freeze, and get it over fast. I think that there is a significant difference on how Debian and Ubuntu work towards a release which means that speaking about a December freeze has very different consequences on each distribution. So, maybe we need to change the terms, so that we are both speaking about the same thing. 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. Again, this was not what was announced, it's not what we were expecting after the We freeze in December plan. I personally wouldn't object to a general let's decide what we want in our distro discussion in December, as long as the freeze is done after those components have been included. That means that if we want March's GNOME, we would have to freeze in April. If we (as in Debian) freeze in December, then there's absolutely nothing to discuss. We already know what we are going to ship. Finally, the whole idea of the time based freezes was to know when we were going to freeze, so that maintainers could work towards that. If the freeze date is decided in the December discussions, then we are back to the current (or past) model, of freezing at some unknown point. -- Besos, Marga -- 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 Thu, Aug 06, 2009 at 04:25:47PM +0200, Matthias Andree wrote: GRUB 2 is going to be another opportunity where Ubuntu can prove either useful or detrimental to your stated goals: invest time to polish it and contribute back to the upstream; or use it raw as it is and leave the user with the shards if it breaks. The upstream abandoned GRUB 1, GRUB 2 isn't ready. This is a good point where people can actually help: GRUB 2 is, besides all other shortcomings, severely underdocumented. Ubuntu as a very user-friendly distribution probably has skilled writers at hand - task some of them to produce useable documentation on GRUB 2. The rest of the mail which I am replying to gets a clear +1. 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
Am Donnerstag, den 06.08.2009, 18:01 +0200 schrieb Marc Haber: On Thu, Aug 06, 2009 at 04:25:47PM +0200, Matthias Andree wrote: GRUB 2 is going to be another opportunity where Ubuntu can prove either useful or detrimental to your stated goals: invest time to polish it and contribute back to the upstream; or use it raw as it is and leave the user with the shards if it breaks. The upstream abandoned GRUB 1, GRUB 2 isn't ready. This is a good point where people can actually help: GRUB 2 is, besides all other shortcomings, severely underdocumented. Ubuntu as a very user-friendly distribution probably has skilled writers at hand - task some of them to produce useable documentation on GRUB 2. But please note that if you want to help with an official GRUB 2 manual, then everyone needs to assign copyright to FSF. -- Felix Zielcke Proud Debian Maintainer -- 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
Philipp Kern tr...@philkern.de writes: On 2009-08-06, Josselin Mouette j...@debian.org wrote: And this is precisely why it was asked that for squeeze, frozen and testing remain different suites during the freeze. Currently I have no idea of whether this will happen. While I see the point of this I don't know if I would be happy. If people just continue with business as usual for unstable and testing we will not release. See the RC bug fixing activity of the last release. A short freeze just means that people would actually have to squash some bugs, but it seems that the majority of DDs simply don't care. Freezing a bit of unstable helps us to apply some peer pressure. Kudos to all of them who helped releasing in the last freezing cycle. I just don't like the perspective of feeling alone in the next one. Those who haven't seen it already might want to watch Theo de Raadt's presentation this year on how OpenBSD releases. It seems directly relevant and very similar to our current release process, except they manage more consistent timing (in large part, I think, because the amount of software they're freezing is smaller and they have more control over it). http://www.youtube.com/watch?v=i7pkyDUX5uM -- 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
On Thu, Aug 06, 2009 at 03:18:08PM +0200, Stefano Zacchiroli wrote: On Thu, Aug 06, 2009 at 02:08:26AM +0200, Cyril Brulebois wrote: Or is some incremental freeze still supposed to happen? During the talk/discussion at DebConf, IIRC Luk stated that incremental freezes had a negative effect because for many developers it was not clear what/when was going to be frozen. The logical consequence drawn there (again, IIRC) has been that the release team would prefer freezing all at once. Note, however, that we have always used to have unblocks during freezes; the policy on how unblocks are handled is completely orthogonal to how sharply you freeze. (Putting -release in Cc to catch their attention.) Keeping that to ensure I'm not on crack with my memories :-) You're not, it's IMHO a faithful wording of our position (with the s/releasing/freezing/ fix ;p) -- 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 wrote: Discussing the validity of security policies is not the point of this thread, so let's leave it at that, please. It is exactly the point of this thread if you use it as an argument against a common freeze cycle. This was only an example, there are others, nitpicking on this one (or any other, for that matter) is pointless. It's OK to bring it up as an argument, but not to counter it? Counter-argument != nitpicking. I wholeheartedly agree there are other examples, pro and con, but since you brought this up as an argument, there's nothing pointless in countering it. Cheers -- Leo costela Antunes [insert a witty retort here] -- 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
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. I'm proud of that. There is unnecessary incompatibility between Ubuntu and Debian. Their incompatible bts is one that personally bits me. The Ultimate Debian Database helps show ubuntu/debian package relationships. http://udd.debian.org/ http://wiki.debian.org/UltimateDebianDatabase Unfortunately Debian and Ubuntu use incompatible bts systems. Currently Ubuntu's launchpad based bug tracking system _bts_ is lacking accessible package version information. Bug tracking information tied to package version is essential for debian where packages go through many version iterations between releases. Package bugs should not be tracked based on the release. They must be tracked based on their version. This was part of the original design for Launchpad Bugs, but it never came to fruition. The very earliest bug still open on Launchpad Bugs asks for this: https://bugs.launchpad.net/malone/+bug/424 Up to and including Hardy, ubuntu used apt-listbugs which referred to debian's bts with package version tracking. Even though this pulled bug information from the debian bts, it gave a reasonable indication of what packages contained significant bugs. apt-listbugs was withdrawn, because ubuntu package customization increasing has made the related debian bts irrelevant. Topic branches and topic trees of are ways by which package customization can be tracked. In order to meet the Debian Collaboration Team's objective the launchpad bts must interface with the debian bts. Only this way developers benefit from the topic branches, trees of distributed package source control. To collaborate bugs must be tracked across both debian and ubuntu and be accessible to both native debian and ubuntu developers.
Re: On cadence and collaboration
On Thu, Aug 06, 2009 at 04:25:47PM +0200, Matthias Andree wrote: [Please Cc: replies back to me, I'm not on debian-proj...@] FWIW, this is an excellent mail, and I share many of your opinions and hindsights here. Note that by your count Debian isn't always a good player with upstreams, I'm pretty sure you will find rotting bugs in the Debian BTS on your packages too ;) -- 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
On 2009-08-06 16:25:47 +0200, Matthias Andree wrote: [I'm Ubuntu developer (MOTU to be more specific), so I might be biased] I certainly won't excuse some things that are not happening, I know that Ubuntu needs to improve in some aspects. But realising this and get things improved are still not the same. I just want to add some data which hopefully explains why things are happening or not happening. 1. General communication with upstream maintainers, and consequences I recently - out of curiosity - looked at the launchpad.net Ubuntu bugs for packages I (co-)maintain upstream. Upstream here is at the origin, not Debian packaging or something, list as above. Some were relevant and still current, and Ubuntu failed to either do something about the bugs (as in debug, write a patch) or at least tell people who were in a position to do something about the problem, concretely, forward the bug upstream. This is the very least you must do. Example: https://bugs.launchpad.net/ubuntu/+source/bogofilter/+bug/320829 This had sufficient information to debug, and lay around for half a year. Nobody in Ubuntu bothered to look at the report, or to forward it to the upstreams. I'm sorry about this but the amount of bugs flowing in into Ubuntu is bigger that can be handled by the available man power, being it developer or community members. Bug #20 was filed March 2008 Bug #30 was filed Nov 2008 Bug #40 was filed Jul 2009 This is around 10 bugs per 9 months, or around 350 bugs per day. While these might include also bugs filed only on projects using Launchpad for bug tracking, the fast amount of them are filed on Ubuntu packages. While this is not really pleasant but it's happening that some bugs are not looked upon for month (or even longer). Another observation is that Ubuntu bugs and bug changes are frequently forwarded to dozens of people, yet nobody cares to look. All you get is me too or dramatic narrations of how the bug ate somebody's dog. From maintainers, such as ubuntu core maintainers, for core packages: deafening silence. When you mean the Also notified list: this list includes people subscribed to bugmail for a package (none are subscribed for bogofilter) and people subscribed to all bugmail. I don't know why so many people subscribe to all bugmail as I certainly couldn't handle that volume. I'm happy to help distributions (without picking any particular, I don't care about your name, but about how you act), but I'm definitely not going to ferret up the downstream maintainers or their bugs. This was a one-time event. Some proposals for Ubuntu's part in this: i. if you can't deal with a bug, tell somebody who can. Leaving it to rot is going to drive users away. I know :( I was about to nearly stop filing bugs myself for this reason (no one commented) before I got involved into Ubuntu and realized myself that there is simply not enough manpower for everything. ii. make package owners explicit. Just assigning package responsibilities for all packages to some opaque mailing list evidently does not work. The list gets my upstream maintainer updates to the bug, yet nobody cares. Unlike Debian, Ubuntu hasn't this one maintainer per package approach (don't know about other distributions). In Ubuntu whole teams are responsible for the components: core-dev for packages in main and MOTU for packages in universe and multiverse. Both approaches have there pro and con. For and a package being in main doesn't necessarily mean that it's better maintained than packages in universe (on a best effort basis). They might only be in main because they are needed by an other package in main (sorry, don't know the reason for bogofilter being in main). While Debian has over 1000 persons with upload rights, Ubuntu counts only 135 persons with upload rights (from those only 56 can upload to main). At the same time there are over 3000 source packages in main and over 12000 source packages in universe. One can easily see that this won't work to get every package the amount of care that it deserves. So in the end many packages are taken unchanged from Debian. Yet bugs don't stop getting filed in Ubuntu and need to be looked at and acted accordingly. Michael -- 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
Michael Bienia mich...@bienia.de writes: I'm sorry about this but the amount of bugs flowing in into Ubuntu is bigger that can be handled by the available man power, being it developer or community members. Bug #20 was filed March 2008 Bug #30 was filed Nov 2008 Bug #40 was filed Jul 2009 This is around 10 bugs per 9 months, or around 350 bugs per day. While these might include also bugs filed only on projects using Launchpad for bug tracking, the fast amount of them are filed on Ubuntu packages. While this is not really pleasant but it's happening that some bugs are not looked upon for month (or even longer). You know those long, heated arguments that Debian has had in the past about web-based bug-tracking systems, reports from users who don't know how to report bugs, how getting a large quantity of bugs isn't necessarily useful compared to getting high-quality bugs, and how making it too easy to report bugs can just result in the bug tracking system being flooded with bugs that no one ever looks at? Yeah, that. Certainly, my experience is that for many of the packages that I maintain in Debian which are also in Ubuntu, the only person who ever looks at the Ubuntu bugs and does anything about them is me. Which is ironic, given that I don't use Ubuntu and can't test directly any of the problems that people report. The apparently partly-automated bug reports from what appears to be your live CD system are particularly bad. Many of them are automated dumps of translated install logs with translated error messages, which drastically limits the number of people who can figure out what's going on. -- 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
Am 06.08.2009, 22:22 Uhr, schrieb Pierre Habouzit madco...@madism.org: On Thu, Aug 06, 2009 at 04:25:47PM +0200, Matthias Andree wrote: [Please Cc: replies back to me, I'm not on debian-proj...@] FWIW, this is an excellent mail, and I share many of your opinions and hindsights here. Note that by your count Debian isn't always a good player with upstreams, I'm pretty sure you will find rotting bugs in the Debian BTS on your packages too ;) Definitely, but I consider myself lucky that the current Debian packagers of my upstream projects are quite good at taking the relevant issues upstream and being responsive and helpful if needed, so at least I'm/we're aware upstream and can see if issues are reported from one end user as a random finding, or if constant streams of reports come from various places. Rotting bugs? Indeed there are some. In doubt, I prefer keeping stable versions going over abandoning them for a development version that is going to be finished many a year in the future. It's annoying to see this if I could overhaul subsystem X and Y, I could finally fix bug 12345 while receiving bug reports or browsing the trackers, but it avoids the far bigger annoyance of letting an old stable version rot and not having a new devel version stable yet -- that would be a real PITN for both end users and downstream distros. -- Matthias Andree -- 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 2009-08-06, Russ Allbery r...@debian.org wrote: The apparently partly-automated bug reports from what appears to be your live CD system are particularly bad. Many of them are automated dumps of translated install logs with translated error messages, which drastically limits the number of people who can figure out what's going on. While the upgrade errors are mildly annoying (somebody *did* expirience them, though), the automated coredump retracing is very, very useful. If anybody hits a segv in my C++ packages and go through the bug reporting process it's obvious what the problem is almost every time. But I guess we'll get there as soon as we have debug packages in place. Kind regards, Philipp Kern -- 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
Philipp Kern tr...@philkern.de writes: On 2009-08-06, Russ Allbery r...@debian.org wrote: The apparently partly-automated bug reports from what appears to be your live CD system are particularly bad. Many of them are automated dumps of translated install logs with translated error messages, which drastically limits the number of people who can figure out what's going on. While the upgrade errors are mildly annoying (somebody *did* expirience them, though), the automated coredump retracing is very, very useful. If anybody hits a segv in my C++ packages and go through the bug reporting process it's obvious what the problem is almost every time. But I guess we'll get there as soon as we have debug packages in place. Yeah, the ones that I was thinking of were the dpkg traces. Automated coredump backtraces would be awesome. The dpkg traces were much less useful. -- 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
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: 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
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: 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: 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: 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
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 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: 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
