Steffen Moeller wrote: > 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. Agreed. And the more different distributions there are, the more left-and-right there is to think about.
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? - Perl - don't even want to go there :-) - GCC - 4.4, 4.5? - X - 1.8? 1.9? - OO.o? - Kernel? 2.6.40? 2.6.42? 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). I don't think such a process could sustainably get beyond the major chunks of infrastructure. But achieving that would itself send a huge signal to the broader upstreams. If nothing else, we may start to see even small upstreams showing up and saying "OK, we'll recommend this version as you 2010 general consensus, and in return if you ship that we'll do point releases to make maintenance easier". Which would be a win for the security teams :-) Mark
