Slashdot Log In
Shuttleworth Calls For Coordinated Release Cycles
Posted by
timothy
on Thu May 15, 2008 10:44 AM
from the that-time-of-year dept.
from the that-time-of-year dept.
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."
Related Stories
[+]
Technology: Dag Wieers Scoffs at Coordinated Linux Release Proposal 240 comments
Nic Doye writes "Dag Wieers responds to Mark Shuttleworth's recent request to ask major Enterprise Linux distributions to synchronise releases, claiming that it 'is no more than a wish to benefit from a lot of work that Novell and Red Hat are already doing in the Enterprise space.' He's confessing to playing Devil's Advocate here, but it is an interesting view from someone with a large amount of experience in the Red Hat/Fedora/CentOS space."
[+]
It's Not Time for OSS Release Cycle Synchronization 110 comments
Bakkies Botha writes "Ars Technica weighs in with some detailed analysis on the controversial issue of open source release cycle synchronization. Ars explains how time-based release cycles work and takes a close look at how the release management strategy suggested by Ubuntu founder Mark Shuttleworth would impact open source software projects. Ars concludes that Shuttleworth's proposal isn't currently viable and argues that the BFDL is overstating the potential to simplify development with better version control tools. Ars also examines a counter-proposal offered by KDE developer Aaron Seigo and explains how it enables users to get the same benefits of synchronization without disrupting upstream development."
[+]
gNewSense Distro Frees Ubuntu 306 comments
Linux.com (who shares corporate overlords with Slashdot) is reporting that gNewSense has gone 2.0. For the uninitiated gNewSense is a stripped down version of Ubuntu's Hardy Heron for the free software purist. Removing over 100 pieces of proprietary code and firmware, gNewSense offers a user the ability to run an OS where everything is able to be studied, changed, and redistributed. "gNewSense is a great alternative to Gobuntu, the Canonical-sponsored free derivative of Ubuntu. According to its wiki page, the 8.04 version of Gobuntu hasn't been released due to a less-than-optimal reaction from the community. Gobuntu used the same repositories as Ubuntu, and the Ubuntu live CD can achieve the same installation as Gobuntu by merely selecting the free-software-only option in the installer (press F6 twice at the boot menu). Also, Mark Shuttleworth, the founder of Ubuntu, has indicated that he would rather focus on gNewSense because the work on that distribution can help the Ubuntu community as a whole. "
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
Components - yes. Distributions - no. (Score:4, Insightful)
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?
Re:Components - yes. Distributions - no. (Score:5, Insightful)
Parent
Re:Components - yes. Distributions - no. (Score:5, Insightful)
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).
Parent
Yuck (Score:4, Insightful)
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.
Re:Yuck (Score:5, Insightful)
Parent
Re:Yuck (Score:5, Insightful)
Parent
Good luck with that (Score:5, Insightful)
The UNIX wars never stopped, BTW, it is just that major components under Linux have been independently developed.
The LSB is a counter-example and a way forward (Score:5, Insightful)
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.
Parent
Matching toolchains, binary compatible apps (Score:3, Interesting)
Distro differences (Score:3, Insightful)
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?
err Gentoo? (Score:5, Funny)
Re:err Gentoo? (Score:4, Interesting)
Users often want to have access to the latest software. Many distributions provide updated packages over time, so that when a new official release comes out, many users already have a good portion of the changes. Gentoo takes this to the extreme, having eliminated the concept of release entirely (except for the installation system). So how does a synchronized release schedule help anyone when users will be upgrading various packages when they are updated?
I just don't see the value in synchronizing releases.
Parent
Re:err Gentoo? (Score:5, Insightful)
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.
Parent
Re:err Gentoo? (Score:5, Funny)
Parent
One reason why Synchronicity is bad (Score:4, Informative)
Unless he is addressing the famous Ro-o-o-o-oxanne, Mr Shuttleworth may mean "synchronization" or "synchrony".
Re:One reason why Synchronicity is bad (Score:5, Funny)
You get to learn that synchronicity also means "the quality or fact of being synchronous".
Merriam-Webster: http://www.merriam-webster.com/dictionary/Synchronicity [merriam-webster.com]
Bartleby: http://www.bartleby.com/61/42/S0964250.html [bartleby.com]
Parent
Re: (Score:3, Funny)
http://www.askoxford.com/concise_oed/synchronicity?view=uk [askoxford.com]
Maybe do it in reverse? (Score:5, Insightful)
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
Loony idea (Score:3, Insightful)
Choice is good. Package QA and selection policies are a big part of what drives the choice.
Hey, Mark: NAK Reject
Re: (Score:3, Insightful)
Sometimes loony ideas are exactly what the world requires - they're the ideas that result in the biggest, baddest, bestest change.
I've been using Ubuntu since Dapper pre-betas, and I tend to agree with you: The "everything new goes into the next release" approach means that I have to wait for upgrades to get cool stuff ('cause there is always cool stuff 'round the corner) and it also means I have to upgrade even if I don't want to, because of the cool
Great Idea (Score:5, Insightful)
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.
Translation? (Score:5, Insightful)
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?
Re:Translation? (Score:5, Interesting)
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.
Parent
What about the load on the servers? (Score:5, Insightful)
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? (Score:5, Insightful)
Parent
Please keep free software PHB free (Score:3, Insightful)
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.
Re:Please keep free software PHB free (Score:4, Insightful)
If you understand how software development happens among professionals, it works just like this. The customer wants a working product and he wants to know when to expect it. The customer has a schedule, too.
You can start your own project to experiment with your art, but some of us are busy making a living here.
Parent
Bad Bad Idea I Think (Score:3, Insightful)
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.
It's about the applications, silly! (Score:3, Informative)
One explanation (Score:3, Interesting)
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 [ubuntu.com]" (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.
Re:One explanation (Score:4, Interesting)
Parent
Would never work for Debian (Score:4, Insightful)
I could maybe see it working for a more commercial organization like SuSE, but not for an all-volunteer effort like Debian.
Re:Anhy reasons not to? (Score:4, Insightful)
Parent
Re:Anhy reasons not to? (Score:5, Insightful)
Parent
Re:Anhy reasons not to? (Score:4, Funny)
Parent
Re:Anhy reasons not to? (Score:4, Insightful)
Ouch
Parent
It's a rate limiting step. (Score:4, Insightful)
Parent
Diversity is Stronger (Score:5, Insightful)
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 [wikipedia.org], with machines to translate among them.
Parent
Re:Diversity is Stronger (Score:4, Insightful)
Parent
Re: (Score:3, Interesting)
What I said was the frequency of opportunity to switch is important. Right now, if your distro doesn't do what you need, but another one issues a release that does do it, you can switch. Any one person might switch that way only once in 10 years. But overall, thousands of people probably switch that way every time a new distro is released with significant differences in version o
Re:Anhy reasons not to? (Score:5, Insightful)
Theres also the fact that for most things except marketing, time based release cycles are a royal PITA, especially short ones. For example i recently read a plasma complaining about being pinned to a 6 month cycle (due to KDE, due to Shuttleworth), because its means they only get to spent 1/2 thier time on real feature development.
Different jobs require different tools^h development cycles.
Parent
Re: (Score:3, Insightful)
Me, I'm going to keep using Gentoo, and pray their admins graduate from grade school before they destroy the whole thing.
Right now, distros follow different goals. Debian is something like 42 years behind everyone, in the name of stability. Red Hat stays about a year behind for the same reasons. Suse, well I honestly don't know what they do. Then you have Ubuntu, where they throw any friggin version Compiz at you, as long as it builds.
There's a good reason for t
Re:Anhy reasons not to? (Score:4, Insightful)
Well, on my computer it wouldn't install a boot loader, because when you boot from the DVD the DVD ends up being
Parent
Re:This idea TOTALLY SUX! (Score:5, Insightful)
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".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.
Parent
Re:This idea TOTALLY SUX! (Score:4, Insightful)
Come on - most people can figure out that things like rpm and apt aren't the "features" I'm referring to. I mean specific features, like Version XX.YY.ZZ of gcc or firefox or kde. If there's a problem with one, better to have only one distro get hit with it because of staggered release dates. Ditto with security problems.
Then there's the extra net traffic caused by more than one major distro releasing simultaneously.
The idea of simultaneous releases for all the major distros is wrong.
Parent
Re: (Score:3, Insightful)
Re:Effect on testing? (Score:4, Interesting)
Anyway, the idea is to have MORE testers, since they would all be at one big bazaar instead of each at their own little one.
More patches would work across distros, and more time could be spent on other things.
The has its problems though. The agreement would force innovation to make people go to one distro over another, but that would only last a cycle or so as the other distros implement the idea (Since they all share in the end).
Maybe if Ubuntu decided to go desktop only, And Suse and Red Hat agreed to split up the server side, maybe, but that is unlikely. Debian will not not do it, they are the stable granddaddy, which can be a good thing.
I like having news on new distros throughout the year also, so it keeps people interested.
It's an interesting concept that might free up some coding time by solving a lot of problems faster and with less overlap, but I don't think it is likely to happen.
One of the strengths of Linux is its diversity (plus we geeks all like our pet projects). IT may help newcomers though, who are scared enough by the number of Vista versions, and are terrified of picking a distro, not to mention learning a new OS.
Parent
Re:Good idea... (Score:5, Insightful)
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.
Parent
Re:I'm definitely for it (Score:4, Informative)
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".
Parent
Re: (Score:3, Informative)