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:
  • Anhy reasons not to? (Score:2, Interesting)

    by spun (1352)
    Seriously, this would be a boon for Linux development in general, filling in the big gaps left by the LSB.
    • 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 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.
        • by TeknoHog (164938) on Thursday May 15, 2008 @04:24PM (#23423886) Homepage Journal
          Fortunately, a Debian maintainer will break the security in their release, even if all distros are released with the same upstream version.
      • 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: (Score:3, Insightful)

          by Eighty7 (1130057)
          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.
    • 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.

       
      • by mweather (1089505)
        So how often do those distros not release with the latest kernel, compiler toolchain, GNOME/KDE, X and OpenOffice versions?
      • Re: (Score:3, Insightful)

        by squiggleslash (241428)

        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 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.
      • 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: (Score:3, Interesting)

          by Doc Ruby (173196)
          No, I don't, nor does anyone else worth considering as a requirement from the overall Linux community. But that's not what I said.

          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
    • 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.
    • Re: (Score:3, Insightful)

      by billcopc (196330)
      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 t
    • I don't want to see this. If everyone is releasing a new version in April, and for whatever reason I need to do an install in May, then I have no choice but a 6-month old distro. I often install Ubuntu / Fedora / SomethingElse depending upon who's got the latest release when I need to install.

      Another reason is the load of distributing the software and problem solving. Imagine what would happen to the mirrors if nobody downloaded a distro for 6 months, then in one month every linux user is downloading a new
    • 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 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?
    • 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).
      • Re: (Score:3, Informative)

        by dotancohen (1015143)

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

        It does disrupt the whole system. Ubuntu LTS had to include a beta web browser (Firefox 3) because the old version would not have been supported by Mozilla for the three years that Canonical has to support the OS.

        • Re: (Score:3, Insightful)

          by 0racle (667029)
          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 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 hairyfeet (841228)
        Um,but isn't it good for Firefox to have some of the more popular releases go out with their beta,as it gets more testers for Firefox? Personally if I was Firefox or Open Office I would want as many testing the software as possible to help me chase down the bugs. That said I'm sure it would be easier for the distros if they new beforehand when the major packages were going to be released as it would give them a timetable to work with. But that is my 02c,YMMV
        • No, because people get the "release" of their distro, use the Beta version of firefox, then complain that it is unstable, and look for something else. Lots of people right now (including me) are having big problems with Flash video in firefox. There is a problem somewhere in the Firefox3-FlashPlayer-Pulseaudio that causes the browser to just crash when watching flash videos. (really frustrating when trying to watch shows on Hulu.com). It was fine when I was running the beta of Ubuntu 8.04, but not cool
      • by PineHall (206441)
        Fedora and Ubuntu seem to be there. Ubuntu is April and October. Fedora is May and November. Those two have a well-publicized schedules and their releases are close to each other. I don't know about OpenSuSE but at least two out of the three big free distributions are pretty much in sync.
      • Re: (Score:3, Insightful)

        by Znork (31774)
        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 some
  • 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.
    • 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.
    • 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.
  • 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.

    • Linux was never part of the UNIX wars. Linux is not UNIX.
    • 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.
    • Mod Parent Down (Score:2, Interesting)

      by mpapet (761907)
      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.
      • by dhasenan (758719)
        I read it more as Shuttleworth saying "My release schedule is good, coordinated releases are good, all popular Linuxes should follow my release schedule."

        There would be a number of benefits to that, but requiring that it be Ubuntu's schedule is a bit puerile.
  • Effect on testing? (Score:2, Interesting)

    by Anonymous Coward
    Simultaneous release schedules = simultaneous betas = testers spread more thinly.
    • by Cryophallion (1129715) on Thursday May 15, 2008 @12:36PM (#23419498)
      Dang it, logged in during preview and lost my post...

      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.
  • by visualight (468005) on Thursday May 15, 2008 @11:51AM (#23418782) Homepage
    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.
  • 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 d

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

        • Re: (Score:2, Insightful)

          by ketilwaa (1095727)
          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.
          • by nahdude812 (88157) *
            A lot of different distributions use the same sets of mirrors (eg, kernel.org, a lot of university sites, etc), so people downloading from single-stream sources like these would compete with each other much more than they do today.

            On the other hand, BitTorrent.
    • Re: (Score:3, Insightful)

      by PHPfanboy (841183)
      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.
      • 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.

        This won't help your situation. It *will* make it worse. Remember, distros customize their products. T

  • 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?
  • err Gentoo? (Score:5, Funny)

    by xav_jones (612754) on Thursday May 15, 2008 @11:56AM (#23418856)
    I use Gentoo, you insensitive clod!
    • Re:err Gentoo? (Score:4, Interesting)

      by crow (16139) on Thursday May 15, 2008 @12:08PM (#23419072) Homepage Journal
      While that sounds a bit snarky, there's a serious point.

      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.
      • 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 mweather (1089505) on Thursday May 15, 2008 @12:14PM (#23419180)
      I'm sure if Shuttleworth knew YOU used it, he would have listed it as a large distro.
  • by Dystopian Rebel (714995) * on Thursday May 15, 2008 @11:56AM (#23418864) Journal
    "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".

  • 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)
    I'd prefer having OSS projects follow the Kaizen constant improvement process than having the project built to order for a given deadline.
  • If it can be semi trivially accomplished something like this would make it easier for developers to develop for Linux. If they can verify it works on multiple systems with only minimal effort it might increase adoption for various aps.
  • 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
    • Re: (Score:2, Insightful)

      by Anonymous Coward
      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).
    • Re: (Score:3, Insightful)

      by myvirtualid (851756)

      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

  • 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.
    • I think this idea should lead to a real advance in quality of the included packages, which will serve the users very well whilst the GNU/Linux pond is small compared to the other ponds there. However as others have pointed out, different distros have different priorities. As soon as the pond becomes sufficiently large that each sub-community (i.e. distro) is big enough to stand on its own two feet there will be an incentive to 'go it alone' as far as release schedules are concerned.

      So for me I'd say this

  • 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:Translation? (Score:5, Interesting)

      by NMerriam (15122) <NMerriam@artboy.org> on Thursday May 15, 2008 @12:16PM (#23419192) Homepage
      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.
    • by xant (99438)
      There's a subtext going on here, though. Hardy has not been a very clean release. A firefox 3 beta was included as the OFFICIAL release, and (at least that particular build) is one of the most unstable in my memory of Firefox. (says someone who was using it when it was still Phoenix.) Lots of crash issues, lots of problems for web developers. Ubuntu is partially to blame, because they could have packaged Firefox 2 and kept it safe; instead they gambled on Firefox 3, and so far, they are losing. Couple
  • One of the things that bugs me about Fedora is that by the time they have historically cobbled a release together, the packages they have elected to include are already a little aged. I recall being stuck on Firefox 1.5 for a very long time (simply because I wanted to keep with the distro without going to too many external sources in order to keep my RPM database as pure as possible) and the same goes for GNOME and OO.o and all sorts of things like that.

    Well, with Fedora9, they went the other way which, I
    • by tobiasly (524456) on Thursday May 15, 2008 @12:54PM (#23419826) Homepage

      One of the things that bugs me about Fedora is that by the time they have historically cobbled a release together, the packages they have elected to include are already a little aged. I recall being stuck on Firefox 1.5 for a very long time (simply because I wanted to keep with the distro without going to too many external sources in order to keep my RPM database as pure as possible) and the same goes for GNOME and OO.o and all sorts of things like that.

      That's just how Fedora rolls. It's their policy (which owes to its Red Hat lineage) that they don't change major version numbers of any component within a release's lifecycle, with the intent that such a policy improves stability of the platform. Now there are certainly arguments to be made on whether that's a good policy, and it mostly comes down to personal preference, but if that's not your cup of tea then maybe Fedora isn't the distro for you.

      That said, as you probably know there are some great 3rd party repos that do have the latest builds, or you can always grab the source RPM from the latest Fedora/Rawhide and compile, but obviously those options also have tradeoffs (both from a "purity"/compatibility standpoint, as well as living closer to the bleeding edge).

      My point is that a distro's upstream inclusion/upgrade policy is one of the major things that sets it apart from the others, and if you're not happy with Fedora's specific policy then you may be interested in either looking at a new distro, or adjusting your expectation around needing to stay "pure".

  • 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 FudRucker (866063)
      I wish I had mod points, Bump parent up +5 Instightful!
    • 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
    • I remember those days too. Fortunately for us today (and like someone else already pointed out) BitTorrent solves that problem entirely and actually makes it easier to download the distributions when everyone is trying to get them all at once.
      • Re: (Score:2, Insightful)

        by shadylookin (1209874)
        That's all well and good for people whose ISPs aren't throttling bittorrent traffic. Some of us however would just be screwed.
    • by RobBebop (947356)

      And on the sixth day, God invented BitTorrent to spread bandwidth concerns across the entire internetwork. And it was good.

      Seriously... once p2p software becomes smart enough to scan for download files that are local for you, you'll be able to get a speeding fast download from your neighbor instead of picking a nearby university that may be anywhere from 1 to 500 miles away.

      • I live in Canada, where Bell throttles their retail customers, and their resellers' customers, you insensitive clod. I don't do P2P. Besides I can *LITERALLY* download faster over dialup at 45 to 50 kbits, than over throttled P2P (30 kbits).

        As a Gentoo user, I don't have to deal with "major releases". I installed Gentoo on my current machine 2 years ago. With Gentoo's slow, rolling upgrade, my operating system is identical to that of somebody who did a new install yesterday. The biggest updates for me
    • 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.

      But that's why RedHat also posted .torrents, so if their servers were slow you could use the community.

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


    huh? Isn't he just asking all the other distro's to adapt to ubuntu's release schedule?
    • Re: (Score:3, Informative)

      by ricegf (1059658)
      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. :-)
    • No, he's actually stating that he would be willing to adjust Ubuntu's release cycle to go along with the consensus of the players. What it appears to be a request for is coordinating at least the next 2 or 3 years worth of release cycles. It appears that Ubuntu still wants to release every six months, but that would not mean the others would have to. But if they could agree that to release annually every May, for instance, then Ubuntu would adjust it's six month schedule accordingly.

      Ubuntu, being one of
  • 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 Builder (103701) on Thursday May 15, 2008 @01:05PM (#23420038)
    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.
  • Love standards... marketing people hate them... all these distros are struggling to get their distros recognized as "the best" for whatever their focus is...

    The first thing a marketing person does when they encounter a standard is try to circumvent it to make the product "unique"...
  • One explanation (Score:3, Interesting)

    by jalefkowit (101585) <jason@jasonlef k o w i t z . n et> on Thursday May 15, 2008 @01:13PM (#23420228) Homepage

    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)

      by manly_15 (447559) on Thursday May 15, 2008 @05:12PM (#23424630)
      I read it on the Ubuntu site when 8.04 first came out that Firefox would be upgraded to 3.0 when it was released. I think their plan is to support Firefox 3 through the 8.04 lifecycle, as Mozilla will be supporting it for at least 18 months as well. But, I can't find anything to this effect now, so perhaps they changed their plans.
  • 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.
  • ...it'd be easy to say "Well it's not that dangerous if it is half-broken, it's three months to next release cycle." I think most do better with the iterative "well now a few Ubuntu/Fedora/Suse/Debian users complained" rather than wait until everyone releases and then get a flood of bug reports.
  • by tangent3 (449222) on Thursday May 15, 2008 @02:18PM (#23421622)
    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
  • 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.

RADIO SHACK LEVEL II BASIC READY >_

Working...