Mark Shuttleworth has written an interesting post about Ubuntu release dates [1]. He claims that free software distributions are better able to meet release dates than proprietary OSs because they are not doing upstream development. The evidence that free software distributions generally do a reasonable job of meeting release dates (and Ubuntu does an excellent job) is clear.
But the really interesting part of his post is where he offers to have Ubuntu collaborate with other distributions on release dates. He states that if two out of Red Hat (presumably Enterprise Linux), Novell (presumably SLES), and Debian will commit to the same release date (within one month) and (possibly more importantly) to having the same versions of major components then he will make Ubuntu do the same.
This is a very significant statement. From my experience working in the Debian project and when employed by Red Hat I know that decisions about which versions of major components to include are not taken lightly, and therefore if the plan is to include a new release of a major software project and that project misses a release date then it forces a difficult decision about whether to use an older version or delay the release. For Ubuntu to not merely collaborate with other distributions but to instead follow the consensus of two different distributions would be a massive compromise. But I agree with Mark that the benefits to the users are clear.
I believe that the Debian project should align it’s release cycles with Red Hat Enterprise Linux. I believe that RHEL is being released in a very sensible manner and that the differences of opinion between Debian and Red Hat people about how to manage such things are small. Note that it would not be impossible to have some variations of version numbers of components but still stick mostly to the same versions.
If Debian, Ubuntu, and RHEL released at about the same time with the same versions of the kernel, GCC, and major applications and libraries then it would make it much easier for users who want to port software between distributions and run multiple distributions on the same network or the same hardware.
The Debian Social Contract [2] states that “Our priorities are our users and free software“. I believe that by using common versions across distributions we would help end-users in configuring software and maintaining networks of Linux systems running different distributions, and also help free software developers by reducing the difficulty in debugging problems.
It seems to me that the best way of achieving the goal that Mark advocates (in the short term at least) is for Debian to follow Red Hat’s release cycle. I think that after getting one release with common versions out there we could then discuss how to organise cooperation between distributions.
I also believe that a longer support cycle would be a good thing for Debian. I’m prepared to do the necessary work for the packages that I maintain and would also be prepared to do some of the work in other areas that is needed (EG back-porting security fixes).
Kudos for this standpoint! It would be really great if the synchronisation coud be achieved!
FWIW: I think synchronizing releases would be great. This would also make patch-sharing between distributions a lot simpler.
One reason I still use Debian is because I believe Ubuntu’s quality is compromised by its desire to meet fixed release dates. So count me against this.
Debian has always had a policy of release when ready. I like that policy and I don’t see why it should be changed, fewer bugs is a better service to users than synchronization with other distros.
Even if release dates aren’t synchronised, feature freeze dates could be. That would give all the same benefits and allow cautious distros more time for bug fixing.
+1 with James
I hope that Debian doesn’t(never) follow the Ubuntu way…
Matt makes a really good point. I think that we could satisfy Mark by agreeing to use the same versions and ship within a slightly larger time window (maybe a few months).
I don’t think that there would be any problem in having a feature freeze as long as 6 months before a major release. We will of course still have back-ports etc.
Again, while I believe the “ship when ready” is one of Debian’s major mistakes, I don’t think there’d be an issue with a feature freeze at an early date. Having all/most of the major linux distros on a synchronised release schedule would be an incredible benefit, and would lead to far greater stability/security within distributions, as it would make patch sharing far easier/more productive/more likely
Though mostly agreeing with both Anouk and James still there’s validity to the proposal. How compatible are distro’s anyway these days ?
Debian is growing older and older with every release upcomming and it is not improving. Just for fun ?
I dont think that I like this idea, I believe that Debian is as stable and as secure as it is because they do release when ready. Why would you want to release a product when it is not? Then you might as well sell out to M$.
Well said, Sir.
All in all, I agree with you. I think Red Hat does a pretty good job of spacing out their RHEL releases, and that would make a pretty good goal for Debian to match. And, as someone who administers a large number of RHEL/CentOS boxes along with a smaller number of Debian boxes, having a closer match of versions for major software packages would definitely ease some of the hassles of synchronizing between them. Obviously there are a few minor issues, as raised here, but I haven’t seen any that seem insurmountable.
I thought one of the things that made Linux harder to exploit on a large scale was the variation and lack of pervasiveness. Do the positives out weigh the negatives? i.e. easier to port apps between distros? – I personally think not
Christopher: I used to work for Red Hat and know how their processes work. While I won’t divulge any details I can tell you that it’s nothing like a sausage factory. ;) I am a Debian Developer, I can’t claim to know anything special about Debian as almost everything that is of interest is published.
I now do a lot of sys-admin work on both Debian and CentOS (with a small amount of Fedora thrown in). So I have seen this from all sides.
Chris: The recent OpenSSL issue would still have occurred only in Debian and not in Red Hat if something like my suggestion had been implemented a few years earlier. There will continue to be plenty of variation between distributions in terms of compile options.
Also we should keep in mind the fact that while having similar versions might make it easier to prepare attacks, it will also make it easier to detect and fix the bugs.
Even if the release date isn’t the same, it might make sense to agree on the same versions of major components, such as the kernel, X, and Samba. That way upstream can plan “Production” and “Crack Smoking” releases. The kernel developers do sync up feature introductions with RHEL and SLES releases.
“You can sort of track 2 major distros’ release schedules but once you get beyond that it gets kind of tough.” — Ted Ts’o at least year’s kernel summit.
http://www.linuxworld.com/community/?q=node/621
[…] in the comments on Russell Coker’s thoughtful commentary there’s a suggestion that I really like – that it’s coordinated freeze dates more than […]
[…] primera respuesta de la comunidad de Debian favorece esta […]
http://www.theregister.co.uk/2008/05/13/ubuntu_linux_synchronization/
I’m cited in The Register.
Would it make sense for the apps to dictate err.. recommend the version that should be used if they are given a time frame to deliver in?
Aka, distributions say we want a version of the Kernel in Jan-Feb 2009
the kernel group then says OK we are willing to support version x and it will be out on Feb 8th 2009. (note dates are same as my question to Mark.