Forgot your password?
typodupeerror
Linux Business Businesses Debian Novell Operating Systems Red Hat Software Software Linux

Shuttleworth Calls For Coordinated Release Cycles 238

Posted by timothy
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."
This discussion has been archived. No new comments can be posted.

Shuttleworth Calls For Coordinated Release Cycles

Comments Filter:
  • by khasim (1285) <brandioch.conner@gmail.com> on Thursday May 15, 2008 @11:49AM (#23418748)
    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?
  • Yuck (Score:4, Insightful)

    by SatanicPuppy (611928) * <.moc.liamg. .ta. .yppupcinataS.> on Thursday May 15, 2008 @11:50AM (#23418768) Journal
    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.
  • by mlwmohawk (801821) on Thursday May 15, 2008 @11:50AM (#23418770)
    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.

  • by trolltalk.com (1108067) on Thursday May 15, 2008 @11:52AM (#23418796) Homepage Journal

    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.

  • by McNihil (612243) on Thursday May 15, 2008 @11:52AM (#23418800)
    Because of security... I am happy that not everybody is on the exact same kernel nor tool chain... all this makes everything into a smaller attack vector. More robust IMHO.
  • by Colin Smith (2679) on Thursday May 15, 2008 @11:53AM (#23418814)
    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.

     
  • Distro differences (Score:3, Insightful)

    by IBBoard (1128019) on Thursday May 15, 2008 @11:54AM (#23418834) Homepage
    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?
  • by bsDaemon (87307) on Thursday May 15, 2008 @11:58AM (#23418884)
    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
  • Kaizen (Score:2, Insightful)

    by Polski Radon (787846) on Thursday May 15, 2008 @11:59AM (#23418894)
    I'd prefer having OSS projects follow the Kaizen constant improvement process than having the project built to order for a given deadline.
  • by Rudd-O (20139) on Thursday May 15, 2008 @12:02PM (#23418950) Homepage
    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.
  • Loony idea (Score:3, Insightful)

    by dbc (135354) on Thursday May 15, 2008 @12:03PM (#23418970)
    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
  • Great Idea (Score:5, Insightful)

    by MrMunkey (1039894) on Thursday May 15, 2008 @12:03PM (#23418980) Homepage
    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.
  • by bcmm (768152) on Thursday May 15, 2008 @12:03PM (#23418992)

    But I'm not seeing why the other distributions matter that much to Ubuntu's release schedule.
    Because Ubuntu is not actually the only Linux distribution, and they can't just tell upstream what to do without seeming very arrogant, unless some other big distributions agree with them.

    Is Ubuntu really going to wait for KDE to wait for SuSE to get GNOME compiled with the latest GCC?
    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).
  • Translation? (Score:5, Insightful)

    by nine-times (778537) <nine.times@gmail.com> on Thursday May 15, 2008 @12:05PM (#23419010) Homepage

    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:Yuck (Score:5, Insightful)

    by zappepcs (820751) on Thursday May 15, 2008 @12:08PM (#23419068) Journal
    If SuSe is late, the cooperation still helped drive KDE being ready for the rest of the Linux world's releases. The bonus is that Linux distros would end up shipping nearly at the same time, and with the same versions of basic system apps. This means that GNU/Linux would be much the same for users by removing annoyances of version differences for downstream developers, and on the whole create a development environment that would compete aggressively with MS's development environment.
  • by knorthern knight (513660) on Thursday May 15, 2008 @12:11PM (#23419114)
    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.
  • by teslar (706653) on Thursday May 15, 2008 @12:11PM (#23419118)

    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 (Score:5, Insightful)

    by mweather (1089505) on Thursday May 15, 2008 @12:12PM (#23419132)

    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:Loony idea (Score:2, Insightful)

    by Anonymous Coward on Thursday May 15, 2008 @12:12PM (#23419134)
    Which is fascinating to me as I think of Ubuntu as the, "we ship every 6 months even if we have a half-dozen show stoppers" distro. Hardy is a horrible horrible mess.

    Shuttleworth needs to keep his hands out of my distro which ships when its ready (as the good programmer intended).
  • by Anonymous Coward on Thursday May 15, 2008 @12:15PM (#23419188)
    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.
  • by trolltalk.com (1108067) on Thursday May 15, 2008 @12:22PM (#23419274) Homepage Journal

    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.

  • by stormguard2099 (1177733) on Thursday May 15, 2008 @12:23PM (#23419296)
    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
  • by Doc Ruby (173196) on Thursday May 15, 2008 @12:24PM (#23419298) Homepage Journal
    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 [wikipedia.org], with machines to translate among them.
  • Re:Loony idea (Score:3, Insightful)

    by myvirtualid (851756) <pwwnow@[ ]il.com ['gma' in gap]> on Thursday May 15, 2008 @12:25PM (#23419320) Journal

    Sometimes loony ideas are exactly what the world requires - they're the ideas that result in the biggest, baddest, bestest change.

    I can hardly stand Ubuntu because it has stale packages

    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 stuff!

    No, I don't believe that I'm contradicting myself: I don't want to upgrade, because I like stable, but I want the cool stuff, so I have to upgrade. Sigh. It is the Ubuntu release cycle that forces me into this.

    That said, I don't plan on switching distros, 'cause I love Ubuntu: Love the mindshare, the community, the approach, the distro itself, etc. It's good stuff. But I would like this pet peeve of mine improved.

    And OK, while I'm at it: I wanted BackupPC 3.0 on my LTS server a looong time ago, and was really looking forward to 8.04 LTS, 'cause I knew the upgrade path would be smooth and BackupPC 3.0 and a lot of other goodness would be there! Yay!

    Guess what? I cannot upgrade my LTS server because I had the temerity to install non-Ubuntu packages (might have been hylafax, I simply have not investigated): The upgrade tool detects the non-Ubuntu package and stops dead. I am stuck with an LTS server that will eventually be unsupported and that will be a real pain to upgrade, because of what seems to me to be a lamo upgrade tool.

    Glad I got that off my chest.

    I Love Ubuntu.

    But I want a release management plan that combines a stable base with rolling releases of the cool stuff. Don't know how this would work, but it seems like a really good idea to me.

  • by Random BedHead Ed (602081) on Thursday May 15, 2008 @12:30PM (#23419412) Homepage Journal

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

  • by ketilwaa (1095727) on Thursday May 15, 2008 @12:43PM (#23419610) Homepage
    Extra net traffic?

    Can you please give some calculations on this? Be sure to compare with when Redmond issues a huge service pack for their latest tragedy.
  • Re:Good idea... (Score:5, Insightful)

    by ricegf (1059658) on Thursday May 15, 2008 @12:47PM (#23419680) Journal

    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.

  • by immcintosh (1089551) <slashdot AT ianmcintosh DOT org> on Thursday May 15, 2008 @01:04PM (#23420030) Homepage

    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.

  • by RiotingPacifist (1228016) on Thursday May 15, 2008 @01:14PM (#23420248)
    Because different tasks need different release cycles, I wouldnt want my 'secure' distro pushing out a version every 6 months, and if I ran a want my 'cutting edge' distro i wouldn't want to sit around for 5 months.
    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.
  • by g2devi (898503) on Thursday May 15, 2008 @01:15PM (#23420266)
    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.
  • by billcopc (196330) <vrillco@yahoo.com> on Thursday May 15, 2008 @01:23PM (#23420448) Homepage
    Sure, go nuts. I see how this could help.

    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 these differences, and while a common release date would give package developers a goal to shoot for, I don't think it would honestly serve the needs of the users because users are different.
  • by Nimey (114278) on Thursday May 15, 2008 @01:24PM (#23420472) Homepage Journal
    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.
  • by Laur (673497) on Thursday May 15, 2008 @01:27PM (#23420532)
    Dude, do you really reinstall a new disto every few months just to get the new version of Firefox or OpenOffice.org? If so, I feel safe in saying that you are in a tiny, tiny minority. If regular people find that they have a crucial need for a newer app they usually figure out how to add an unofficial repository rather than switching to an entirely different distro, where the problem will just repeat a few months down the road.
  • Re:err Gentoo? (Score:5, Insightful)

    by Tanktalus (794810) on Thursday May 15, 2008 @01:30PM (#23420592) Journal

    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.

  • by shadylookin (1209874) on Thursday May 15, 2008 @01:35PM (#23420722)
    That's all well and good for people whose ISPs aren't throttling bittorrent traffic. Some of us however would just be screwed.
  • by PHPfanboy (841183) on Thursday May 15, 2008 @01:43PM (#23420884)
    We write software for Linux users. Keeping up to date with the latest releases sends our packaging and testing teams into extra, unplanned cycles as our customers demand the latest Linux stuff is always supported and we have no control over what is release and when. Synchronized release cycles would be a major boon for the thousands of companies writing software for commercial Linux users/companies/ISVs.
  • by Anonymous Coward on Thursday May 15, 2008 @01:47PM (#23420972)

    Because of security... I am happy that not everybody is on the exact same kernel nor tool chain... all this makes everything into a smaller attack vector. More robust IMHO.
    Ahh... the Security by Obscurity argument.

    Ouch
  • Re:Yuck (Score:1, Insightful)

    by Anonymous Coward on Thursday May 15, 2008 @01:59PM (#23421224)
    So basically exactly like what we have already.
  • by corstar (916066) on Thursday May 15, 2008 @02:40PM (#23422060)
    Debian has the best motto; "Release when it's ready". That's the best policy to have imho 'Nuff said
  • by squiggleslash (241428) on Thursday May 15, 2008 @02:42PM (#23422098) Homepage Journal

    On the other hand, it will also slow down developers to and force them to take an attitude of "If I make this rely upon the just released and completely virtually untested features of kgnomevx11lib.so.4.0.11, then there's no chance anyone will ever run my program beyond a tiny group of Gentoo users in the next two years, so my better option is to actually do this properly and make it work with existing, widely used, systems."

    And frankly, that'd be a good thing.

  • by Znork (31774) on Thursday May 15, 2008 @03:04PM (#23422540)
    If this had existed by now, Mozilla would have known when to aim for a Firefox 3 release

    And instead of distributions including beta 5 we'd have Firefox beta 5 under the name of Release instead. Political pressure to adopt release schedules doesn't necessary mean the actual software gets finished any faster.

    It's not proprietary software we're talking about; there isn't a seven year release cycle with massive changes between each revision. For the 6-9-month dists, who really cares if a certain version of something makes release or not? The next release isn't exactly far away, and in many cases a staggered release allows more bugs to be reported by early adopters and fixed before everyone rolls onto the release in question.

    For the long term releases it might make more sense to synchronize some things like kernel versions and support libraries, but mostly because it'd make it easier for proprietary software makers to target more similar versions. But then again, I'm not sure it's in the best interest of free software vendors to bend over backwards to make it simpler for proprietary vendors; had it been up to the proprietary vendors everyone would be stuck at a release years ago and progress would slow to a crawl. So perhaps it's better to just move forward and force everyone to develop and implement methods to keep up with a permanently changing target.
  • by 0racle (667029) on Thursday May 15, 2008 @03:43PM (#23423234)
    RHEL seems to do fine with that. Then again, Red Hat will support whatever packages they ship even if upstream drops it. Beyond repackaging, what exactly does Ubuntu do?

    This is a request for everyone to follow Ubuntu's schedule so Ubuntu can continue to do nothing while still providing a "LTS" branch. It's not Ubuntu LTS if Ubuntu can't support it over the long term.
  • by HiThere (15173) <charleshixsn@ear ... t ['hli' in gap]> on Thursday May 15, 2008 @05:57PM (#23425314)
    Currently one distribution goes first and takes it's lumps finding where the problems are. Consider the Hardy Heron Re-Mix. Not ready for use, where the default Hardy Heron is quite sound....except...

    Well, on my computer it wouldn't install a boot loader, because when you boot from the DVD the DVD ends up being /dev/hda. So I installed Debian in a different partition, and now it works fine. Yes, I reported the bug, but I didn't try it before the release, so I didn't report it before the release. Now just imagine that ALL of the distros had released at the same time? There wouldn't have BEEN a fall-back position.
  • by Chris Snook (872473) on Thursday May 15, 2008 @06:19PM (#23425582)
    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.
  • by FranTaylor (164577) on Thursday May 15, 2008 @06:35PM (#23425778)
    The problem is that Linux is not your plaything, it's what people use to run their databases and web servers on.

    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.
  • by Eighty7 (1130057) on Friday May 16, 2008 @01:25AM (#23429250)
    More like security by diversity. It's the difference between hiding a key under the doormat & having a different key than your neighbor. Hiding your hashes vs salting them. The burglar may know your system quite well - point is you don't want him to get two houses with the same amount of effort.

Some people carve careers, others chisel them.

Working...