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."

Comments

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: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:[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 /.?