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

err Gentoo?

[xav_jones]

I use Gentoo, you insensitive clod!

Re:err Gentoo?

[mweather]

I'm sure if Shuttleworth knew YOU used it, he would have listed it as a large distro.

Re:err Gentoo?

[Tanktalus]

I have four boxes running Gentoo (some were switched from RH, others have always had Gentoo). Yet that doesn't prevent me from seeing value in synchronising releases among other distros.

What it does give is:

• Provide incentive for major components (KDE, Gnome, OOo, Xorg, firefox, etc.) to release a month prior to that point to be sure their first set of fixes can make it to "most" distros to provide out-of-the-box benefits to users. This incentive is there for smaller components (e.g., bash, vi, emacs), too, but not as strongly, nor do they affect the OotB experience as much. This even helps Gentoo users in getting a more predictable update. It also hurts us in that we'll be upgrading many major pieces of our systems all around the same time.
• Provide a broader base for testing all of these components: when you get the Ubuntu testers, the Fedora/RH testers, the SuSE/SLE[CS] testers, and Debian testers all testing basically the same code base, you should uncover more bugs faster. Sure, there are some people who test multiple distros who won't have the time to do it this way, but I don't imagine that's a huge percentage. This, too, helps Gentoo users, in that we're not the only ones testing the latest versions... yet between these cycles, we are among the few testing them.
• More advertising. Imagine a united push for Linux from all the major distributions! Even if they weren't united, there'd be more buzz around linux from all quarters - Ubuntu fans, RH fans, SuSE fans, Debian fans, etc. - about the "upcoming release" of their Linux distribution. Non-Linux users would merely here "upcoming Linux release" - from more people at a time. And RH and Novell likely would still take out their standard advertising in papers, online, wherever, which people will see more of (some from RH, some from Novell), and it feeds off each other. This obviously helps those willing to pay for advertising more, but it also helps all distributions as we end up with more Linux users (thus more bug reports, thus better quality; more numbers means more incentive for Linux drivers from our favourite hardware vendors, which will help all distros). This helps us Gentoo users like any increase in Linux numbers: quality and drivers. This gets even better if all these distros worked together for common advertising, but that's probably a bit much to hope for.

What it costs us is diversity. As has been pointed out, there will be more homogeneity in the Linux world, which is always bad for exposing attack vectors. And that affects us on Gentoo, too - there will be a period of time where Gentoo will be at about the same level as everyone else (right near after the release - new ebuilds won't be marked stable for a while after that as I'm sure everyone will be taking a break after the harried development cycle), which means that any security issues that everyone else has will also affect us on Gentoo. Until they're discovered, then we gain the advantage again.

The question is: is the value in this great enough to offset the risk? Microsoft has always opted for marketing bells and whistles over security, and it has generally worked for them - do we want to start down that road just to gain a bigger marketshare today? That doesn't mean there is *no* value in synchronising, we just have to weigh it carefully.

Maybe do it in reverse?

[bsDaemon]

Leave Debian out of this for the moment, because it seems to take them a few years to get a major release out the door...

Instead of getting commercial Red Hat and SuSE on board, why not get Fedora, which feeds into RHEL, on board first?

Ubuntu and Fedora just put out releases within a month of each other, so it wouldn't take much to keep the schedules synced from on out. Maybe get some other popular community distro on board next.

RH will probably fall into step by default, which would be nice (i guess -- i can't buy it at the store anymore, so wtf do i care what they do?) then.

trying to get the free-be to dictate to major corporate distros that have been around for a hot minute is not likely to happen. imho

Re:Anhy reasons not to?

[Rudd-O]

Exploits for Linux distributions of the same arch usually work across distros and kernel version brackets, and the toolchain doesn't have an influence on them. So your point is moot.

What about the load on the servers?

[knorthern knight]

Many universities and other publically-spirited sites mirror several distros. Different release cycles spread out the load on these servers. Having multiple distros being updated at once will result in more people updating at the same time. The result would be servers sitting almost idle for periods of time, with short periods of "server not available".

This is not a joke. I remember, years ago, when Redhat was *THE* major end-user distro. When a new version came out, regular users would have to wait a week or so before they could download it.

Re:What about the load on the servers?

[stormguard2099]

I'm all for this. For a few glorious days every so often we can actually say that the majority of bit torrent traffic IS linux distros

Re:This idea TOTALLY SUX!

[teslar]

All this would do is ensure that people stick with their current distros. After all, if they all come out on the same date, you're going to grab the one you're currently using, and upgrade. Then you won't have as much incentive to try another one that came out on the same date, since you just finished the upgrade

Err... I don't know about you specifically but I think in general you'll find that people tend to stick to their distro regardless of the update cycles unless there is a major reason to switch. Can you imagine what a mess it would be to constantly switch to whatever distro has the latest release?

Me, I switched once - from debian to Ubuntu (Breezy at the time). And I didn't really consider that a switch because I just saw (and to some extent still do) Ubuntu as a " version of debian which works better straight out of the box".

and they'll all most likely have the same features.

Not true. For instance, Fedora will have rpm, Ubuntu will have apt. And if at some point you decide that rpm suits your needs better than apt (just an example), you will switch regardless of the release cycle.

Re:Yuck

[mweather]

What happens when one runs behind? Does it delay the rest? If they can't meet the pre-determined release date, then they get delayed, nobody else is required to wait for them.

Re:Translation?

[NMerriam]

I think that's half the idea -- to provide an external motivator for packages to wrap things up and release something stable periodically.

The other half of the idea is that it provides a more uniform platform for software/hardware support -- the idea being that Adobe or NVidia could make a release that works with all the March 2019 distros, and support people could offer support for the March 2019 distros. It is, after all, one thing to be familiar with the package management of 5 different distros, and another thing entirely to be familiar with the specific point release quirks of the software packages on 5 different distros.

Of course reality would be nowhere near as elegant as this theory.

Diversity is Stronger

[Doc Ruby]

Yes: the different release schedules mean that in nearly any given month, I can turn to a different distro for a full release, tested by their independent beta populations, without waiting for the "synchronized Christmas".

I understand that synchronization will make Shuttleworth's life easier, on the supply side. But it will reduce the diversity in the Linux ecosystem. People will not have switching opportunities between different distros when they want to get a new complete (and supported) release before their current distro's is ready. Which might be good for Shuttleworth, with the dominant market share, but it's not good for anyone else.

Which is why I think the other distros won't go for it. And why I'm happy about it.

The Cathedral is obsessive about monopolizing the calendar. But in the Bazaar, we can each have whichever calendar we want, with machines to translate among them.

Re:Components - yes. Distributions - no.

[Random BedHead Ed]

Is Ubuntu really going to wait for KDE to wait for SuSE to get GNOME compiled with the latest GCC?

No. Shuttleworth isn't suggesting the distros wait for anyone else, but rather that they set a well-publicized schedule by which they coordinate their respective releases - say, April and October (to borrow Ubuntu's schedule). Then the makers of GNOME, KDE, GCC, GIMP, Firefox, OpenOffice.org, etc. will know that April or October is the month to shoot for in order to ensure their latest releases are finished in time for inclusion in the most popular distros. But Shuttleworth is stressing that it doesn't have to be April and October - that he'd happily change Ubuntu's schedule as long as a few distros can agree on something. This is a great idea. If this had existed by now, Mozilla would have known when to aim for a Firefox 3 release so that OpenSUSE, Ubuntu, Fedora and any other coordinated releases would be able to distribute their official 3.0 (and not beta5, as a couple distros decided to do).

The LSB is a counter-example and a way forward

[g2devi]

You're forgetting the Linux Standards Base.

Ubuntu, Debian, Red Hat, SUSE, and others already agree to shipping the LSB for some time now.

If at least three of these can agree to ship the same LSB version at approximately the same time, they won't be doing anything new, but they could gain the benefit of sharing bug reports, sharing device drivers (since a standard kernel would be the focal point for driver development), even sharing management tools (since they all assume the same LSB version), and better support from 3rd party proprietary products like Flash, Oracle, and VMWare (which still hasn't shipped a working version for the Ubuntu LTS kernel). Granted, the last point might cause, FSF devoties to throw fits, but unfortunately some of us wouldn't be able to move to Linux without these products (e.g. I use Oracle at work and my wife needs VMWare to access some windows specific functionality on her bank that crashes KVM and VirtualBox and does not work at all in WINE).

Given that the LSB already exists, I see little downside in taking this one step and lots of upsides.