Shuttleworth Calls For Coordinated Release Cycles

voodoosws points out on Mark Shuttleworth's blog Shuttleworth's call for synchronized publication of Linux distributions, excerpting: "There's one thing that could convince me to change the date of the next Ubuntu LTS: the opportunity to collaborate with the other, large distributions on a coordinated major / minor release cycle. If two out of three of Red Hat (RHEL), Novell (SLES) and Debian are willing to agree in advance on a date to the nearest month, and thereby on a combination of kernel, compiler toolchain, GNOME/KDE, X and OpenOffice versions, and agree to a six-month and 2-3 year long term cycle, then I would happily realign Ubuntu's short and long-term cycles around that. I think the benefits of this sort of alignment to users, upstreams and the distributions themselves would be enormous. I'll write more about this idea in due course, for now let's just call it my dream of true free software syncronicity."

One reason why Synchronicity is bad

[Dystopian Rebel]

"Synchronicity" is a term invented by Carl Jung and made popular by a pop-music band with a singer whose irritating high voice keeps listeners awake when his dreary pretension threatens to put them to sleep.

Unless he is addressing the famous Ro-o-o-o-oxanne, Mr Shuttleworth may mean "synchronization" or "synchrony".

Re:Good idea...

[Rudd-O]

Didja even read the fucking article? He's NO WAY EVEN CLOSE to acting like the boss of Linux.

Re:Good idea...

[Steve Max]

Why should other distros adapt to Ubuntu's timeframes? Fedora is already in a 6-months schedule; OpenSUSE releases aren't time-based but feature-based; Mandriva has their own 6-month schedule; and so on. It works for them. If Shuttleworth is so keen on having synchronized releases, he should move the next Ubuntu to match, say, the next Fedora. This will give him and the users the benefits he wants without needing any interproject discussion.

Re:Good idea...

[TLZ9]

RTFA

"If two out of three of Red Hat (RHEL), Novell (SLES) and Debian are willing to agree in advance on a date to the nearest month, and thereby on a combination of kernel, compiler toolchain, GNOME/KDE, X and OpenOffice versions, and agree to a six-month and 2-3 year long term cycle, then I would happily realign Ubuntu's short and long-term cycles around that."

He's explicitly writing that he would adapt his Ubuntu's release to a date set by others.

Re:I'm definitely for it

[tobiasly]

One of the things that bugs me about Fedora is that by the time they have historically cobbled a release together, the packages they have elected to include are already a little aged. I recall being stuck on Firefox 1.5 for a very long time (simply because I wanted to keep with the distro without going to too many external sources in order to keep my RPM database as pure as possible) and the same goes for GNOME and OO.o and all sorts of things like that.

That's just how Fedora rolls. It's their policy (which owes to its Red Hat lineage) that they don't change major version numbers of any component within a release's lifecycle, with the intent that such a policy improves stability of the platform. Now there are certainly arguments to be made on whether that's a good policy, and it mostly comes down to personal preference, but if that's not your cup of tea then maybe Fedora isn't the distro for you.

That said, as you probably know there are some great 3rd party repos that do have the latest builds, or you can always grab the source RPM from the latest Fedora/Rawhide and compile, but obviously those options also have tradeoffs (both from a "purity"/compatibility standpoint, as well as living closer to the bleeding edge).

My point is that a distro's upstream inclusion/upgrade policy is one of the major things that sets it apart from the others, and if you're not happy with Fedora's specific policy then you may be interested in either looking at a new distro, or adjusting your expectation around needing to stay "pure".

Re:big change for ubuntu

[ricegf]

Or offering to realign Ubuntu's short and long-term cycles around a schedule agreed by the other major distributions, depending on whether your English comprehensions skills are faulty here, or mine. :-)

It's about the applications, silly!

[Builder]

I can definitely see how this would be of major benefit to all Linux users who don't use SLES or RHEL. By having a synchronised release, there would be a better chance of major libraries like glibc and compiler versions being in-sync. This would increase the chances of getting ISVs to support something other than just RHEL or SLES which is mostly the current case for large software apps.

A good idea, much like the Eclipse Project

[tangent3]

The Eclipse IDE Project uses a similar idea for its releases, where the main plugins (CDT, JDT, PDE, RCP, etc) are required to synchronize their releases with the release of the core Eclipse Platform.

Re:Components - yes. Distributions - no.

[dotancohen]

Why the hell would KDE wait for SuSE? It doesn't matter if upstream is ready a little before downstream. However, if it happened the other way 'round, SuSE would have the option of either releasing a little late or not including that version. This wouldn't disrupt the whole system because no one is waiting for the distros (well, except the users).

It does disrupt the whole system. Ubuntu LTS had to include a beta web browser (Firefox 3) because the old version would not have been supported by Mozilla for the three years that Canonical has to support the OS.

Re:[CITATION NEEDED]

[Daengbo]

Bugs in old code don't matter. Canonical released 8.04 "LTS" with a bunch of known bugs. Several of these were related to the replacement of Gnomevfs and ESD with Gvfs and PulseAudio.
1. Audio locking with Flash or FF crashes with libflashsupport -- your choice of one.
2. Yanking a removable drive without unmounting first leaves the drive mounted and browsable (in cache), but it can't be unmounted and writes fail (of course).
3. F-Spot (now the default photo app) can be run once on 64bit, but GConf entries written on first run cause the app to SIGSEV on subsequent attempts.
...

The list is enormous. Canonical should have delayed a couple of months just like they did for 6.06, but they were too interested in making their time-table and bragging about it.

If you think I'm off-topic, the timeliness brag is a the beginning of TFA.

By the way, what happened to the ordered and unordered lists on /.?