Slashdot Mirror
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."
Seriously, this would be a boon for Linux development in general, filling in the big gaps left by the LSB.
- None can love freedom heartily, but good men; the rest love not freedom, but license. -- John Milton
I see the attraction of having the latest releases of KDE and GNOME and so forth.
But I'm not seeing why the other distributions matter that much to Ubuntu's release schedule.
The more items you have to sync, the more difficult it gets to be. Is Ubuntu really going to wait for KDE to wait for SuSE to get GNOME compiled with the latest GCC?
I can't imagine multiple development teams running under completely different chains of command syncing their release cycles. What happens when one runs behind? Does it delay the rest?
I can see the benefits with regards to the software that is common to most linux distros, but I can't see all those companies ever working together that closely.
ad logicam Claiming a proposition is false because it was presented as the conclusion of a fallacious argument.
Here we have a perfectly reasonable proposal that would help a whole segment of the industry and it has a snow balls chance in hell.
The UNIX wars never stopped, BTW, it is just that major components under Linux have been independently developed.
Simultaneous release schedules = simultaneous betas = testers spread more thinly.
First thing I thought of is being able to mix repos of several distributions. I don't think RH and Novell will do it, just for that reason.
Samsung took back my unlocked bootloader because Google wants me to rent movies. They're both evil.
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, and they'll all most likely have the same features.
On the other hand, having different distros purposefully unsynchronized allows for new features to be introduced and widely disseminated one distro at a time, so if there's a security or other problem, it doesn't affect almost everyone from day zero.
So, not only is the proposal anti-competitive, it's inherently insecure.
Kevin Smith on Prince
It will slow down development progress, reduce competition between distributions. If Ubuntu, RedHat or Suse are unable to keep up with each other then they fall by the wayside, that's the nature of a competitive market.
Deleted
So what will be the distro differences? I thought "how to update the packages are" was one of the decisions people made. Surely synching with Debian would put everyone's schedule back a bit and be a bit pointless since they're not likely to be using the same versions of things.
Also, would it really help upstream? If everyone is going for the same dates then surely upstream will have periods when feedback is at a low because everyone is focussing on assembling the final distro and the integration?
I use Gentoo, you insensitive clod!
"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".
Rich And Stupid is not so bad as Working For Rich And Stupid.
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
I'd prefer having OSS projects follow the Kaizen constant improvement process than having the project built to order for a given deadline.
A key differentiator among Linux distros is package inclusion policies and release policies. Some people like Ubuntu because it has "stable" packages -- I can hardly stand Ubuntu because it has stale packages. I prefer rolling-release distros -- Shuttleworth's idea doesn't even have a translation into that world.
Choice is good. Package QA and selection policies are a big part of what drives the choice.
Hey, Mark: NAK Reject
I think this is a great idea from the perspective of people who currently do not use Linux. From their view point they see Windows, Mac OSX, and Linux. They don't know that there's Debian, RedHat, SuSE, Ubuntu, etc., nor do they care. If the release schedules are at least somewhat in sync, then each distribution should be using the same, or close to the same, kernel, library and program versions. The only differences between them would then be the distributions' customizations of those packages. In my opinion I think that it could help to bring Linux to be a bit more mainstream and be more competitive, at least in the desktop market. However, I do think that it should be a consensus among groups rather than having one "master" directing everything. The idea just would not work that way.
I also think it would be a good idea from the current Linux users' perspective as well. It would make it easier to compare distributions head-to-head.
So I'm not sure I understand the big idea here, but let me give it a shot. Shuttleworth is suggesting that if the big distributions all synchronized their releases, it would set clear targets for the upstream developers, e.g. the people at OpenOffice could say, "Let's be sure to get a new release ready for all the November '09 Linux distribution releases."
So it would start a sort of natural schedule for developers to work on stabilizing their projects at regular intervals... or something like that. Is that what he's getting at? Am i close?
Didja even read the fucking article? He's NO WAY EVEN CLOSE to acting like the boss of Linux.
Rudd-O - http://rudd-o.com/
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.
I'm not repeating myself
I'm an X window user; I'm an ex-Windows user
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.
PHB's have already destroyed the fun of coding at work. Don't let them do it free software as well.
Software is more of an an art than a science. It's done when it's done.
Every project I've been in where we've had to rush to meet some PHB's arbitrary deadline dramatically increases the shipped bug count and results in less maintainable software. In contrast, the "ship it when it's done" model releases within month of the arbitrary deadline, but with 1/10th as many bugs. This is mainly because in those situations we're not deathly afraid of breaking the release line, so we have the option of completely refactoring a primary component to get rid of design bugs.
PHB's don't understand this simple concept: refactoring early and often saves money in the long run. Step 2 in the elusive profit model is "do { Refactor(); } while (!AllTestsPass());"
p.s. Posting anon because my current project at my day job is managed by a PHB; and yes, I do code outside of my day job -- just not for PHBs.
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.
--
make install -not war
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.
Actually, he didn't ask other distros to match Ubuntu. He was asked when an event would occur, and he replied with a date unless the major distros decide to synchronize releases
I read that as Ubuntu's willingness to change their schedule to match a common one, should other distros agree.
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".
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. :-)
I'd really rather see projects like OpenOffice, KDE, GNOME, X, etc., get released on a "when it's ready basis" than seeing them all bending to the collective will of the major Linux distributions. Once Ubuntu et al. all decide they want October release dates or whatever, I imagine major projects will start getting pressured to conform as well, regardless or whether or not it makes any SENSE for them to have their releases at that point.
For a Linux distro (assuming you don't use a rolling release system which I personally prefer), it makes sense to have regular dates where you update your system to all the latest. The only "benefit" I could see coming out of a synchronized release cycle is to pressure projects to conform to that cycle too--otherwise what's the point--and for projects like OpenOffice that sort of thing just doesn't make any damn sense. Add to that the additional bureaucratic layers and inefficiency introduced by having to coordinate even more stuff...
I for one hope this falls flat.
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.
I'm surprised that nobody yet has mentioned the most obvious reason why Shuttleworth would want this.
Canonical shipped shipped their latest Ubuntu release, 8.04 ("Hardy Heron"), last month. Canonical wanted Hardy to include Firefox 3 instead of the getting-a-bit-long-in-the-tooth Firefox 2. However, since Mozilla's release target for FF3 was a month after the release target for Hardy, Ubuntu had three choices, none of them ideal: put off the move to FF3 for the next release (six months down the road), ship Hardy with a beta version of FF3, or delay shipping Hardy until FF3 had shipped. They ended up shipping with Firefox 3 Beta 5.
This matters because Hardy is a so-called "Long Term Support" (LTS) release, which Ubuntu commits to supporting for eighteen months instead of the standard six (for customers who don't want to be updating their OS every six months). So now Canonical is on the hook to support a beta release of Firefox until long after FF3 final is released and the betas are forgotten.
I would presume that Shuttleworth wants coordination in distro release cycles because it would give him more leverage with third parties in situations like this. If Canonical says to Mozilla "hurry up and finish FF3 so we can make our release date", that's easy to ignore because it's just one distro. If EVERY distro is saying that to Mozilla, they'd be more inclined to listen -- and probably more likely to orient their own release cycles to fit with those of the distros.
Read my blog.
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.
Debian's organization would have to make a major fundamental change to stick to an actual release schedule. They have /never/ been on time for a release, preferring to wait until enough of the packages don't have release-critical bugs.
I could maybe see it working for a more commercial organization like SuSE, but not for an all-volunteer effort like Debian.
Hail Eris, full of mischief...
E pluribus sanguinem
There's absolutely nothing reasonable about Shuttleworth's request.
1. It's a Trojan Horse to legitimize Shuttleworth's business prospects. Simultaneously he'll out-shout Debian and give him a platform with which to more easily compete with Novell. Given Novell's history of mismanagement, I'd say they are helping him already.
2. There will be _lots_ of ubuntu users ready to mod me down for comment #1. Let's entertain the notion that I am completely misguided and I fall in line with the Ubuntu groupthink. What exactly would be accomplished? Nothing. Ubuntu already forks from Debian early on and as far as I can tell, never the twain shall meet.
3. Debian still releases when ready. Ubuntu releases on a calendar, warts and all. Imagine if the Debian community fell under Shuttleworth's and changes to a firm "ready or not" release schedule. It would slowly turn the Debian project into Shuttleworth's fiefdom rotting it from the inside.
http://www.maxineudall.com/2010/02/should-economists-be-sued-for-malpractice.html
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.
Debian has the best motto; "Release when it's ready". That's the best policy to have imho 'Nuff said
That's because of your UID being over one million.
"When I first heard Daydream Nation it quite frankly scared the living shit out of me." -- Matthew Stearns
Yes, but I have found that new versions of software often have bugs in them. Sometimes causing system failure.
If Suse or RH want to hold back on a new release or RH wants to jump up and be the beta tester for a new version then more power to them. I think that while Shuttleworth may be well intentioned, it would ultimately be a disservice to the linux community for multiple reasons. Security and reliability being the number one reason.
I really think Shuttleworth knows this and is making this statement more to get advertising for his distro than for anything else.
RH and Novell have large customers and are well acquainted with their needs. If in the process they find that certain packages cause problems, they may postpone a release. RH and Novell accepting a release cycle plan based on the communities "We just want to know" or "I have a dream", just isn't going to be a good business decision at this time. And I don't think it makes sense for the Linux Community as a whole either.
I actually stumbled across this last night on firehose or something. No comments had been posted yet and I thought it was a joke along the lines of something in the Onion.
He who said 1,000,000 monkeys on 1,000,000 typewriters would eventually type the great novel, never saw an AOL chat room
I work for a Linux vendor (though I speak only for myself), so take this with a grain of salt...
Personally, I think the staggering of releases between RHEL, SLES, and Ubuntu LTS is *good* for the community, and ultimately the customers as well. If all the enterprise distros synchronized, we'd see a much more pronounced oscillation between adding new features and improving existing code. Currently, someone somewhere is always preparing for a stable release, while someone else has just pushed one out and is addressing the issues that only crop up when customers deploy widely in production, and someone else is in the middle of their life cycle and working on major features they plan to support in their next version. This ensures a constant hum of work on all fronts that keeps community specialists busy in their various areas of expertise, and ensures that hardware and application vendors always have an incentive to post their work as soon as it's ready.
Can you imagine what would happen to the quality of upstream code if developers knew that nobody was going to run it through a heavy QA matrix for the next two years? I shudder to think. Worse, this would draw a much larger distinction between community and enterprise distributions, which might be good for some of the existing enterprise players until new competition comes along and bucks the trend, but would certainly harm innovation, even in the short run. Volunteers may contribute a minority of the lines of code that ship, but their constant involvement in the development process ensures that the enterprise developers don't get too far off track. New software technology always spends time maturing in the enthusiast realm before it gets adopted by the enterprise.
If this proposal is accepted by all of the enterprise vendors, it will lead to forks. Unlike some forks which increase the diversity of research and development, these forks will actually reduce it, because they will draw the majority of the labor away from the innovation and into glorified support.
Linux used to have a stable/unstable release model. It worked for a while, but ultimately it interfered with getting new technology into the hands of the users. We now have the economies of scale that allow us to have frequent stable community releases, with both quality and feature work at every step. We would be fools to give this up.
There's no failure quite as dissatisfying as a complete and total solution to the wrong problem.
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
Put identity in the browser.