Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Shuttleworth Calls For Coordinated Release Cycles

timothy posted more than 6 years ago | from the that-time-of-year dept.

Linux Business 238

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

cancel ×

238 comments

Sorry! There are no comments related to the filter you selected.

Anhy reasons not to? (2, Interesting)

spun (1352) | more than 6 years ago | (#23418718)

Seriously, this would be a boon for Linux development in general, filling in the big gaps left by the LSB.

Re:Anhy reasons not to? (4, Insightful)

McNihil (612243) | more than 6 years ago | (#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.

Re:Anhy reasons not to? (5, Insightful)

Rudd-O (20139) | more than 6 years ago | (#23418950)

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.

[CITATION NEEDED] (-1, Troll)

bcmm (768152) | more than 6 years ago | (#23419080)

LOL WUT?

Re:[CITATION NEEDED] (1)

maxume (22995) | more than 6 years ago | (#23419204)

U tlk GoodLay.

Anyway, exploits aren't something that always show up in new code, they are often found in old code, so a given exploit will affect several versions of whatever package, and several distros will have a version of the package that is susceptible to a given new exploit. That is, security problems are almost always a good deal older than their discovery.

Re:Anhy reasons not to? (1)

McNihil (612243) | more than 6 years ago | (#23421150)

Tool chain builds the glibc et.al. The tool chain also builds the kernel. The tool chain is capable of building itself from scratch.... so I fail to see how this is not a place where one can significantly thwart a system. Having different versions of glibc et.al. definitely makes the attack vector smaller.

And no this has little to do with security through obscurity (as some in the replies have raised) ... this has to do with resilience against total collapse of a system... how goes the saying about having all ones eggs in one basket?

Re:Anhy reasons not to? (4, Insightful)

Anonymous Coward | more than 6 years ago | (#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

It's a rate limiting step. (4, Insightful)

Colin Smith (2679) | more than 6 years ago | (#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.

 

Re:It's a rate limiting step. (1)

mweather (1089505) | more than 6 years ago | (#23419094)

So how often do those distros not release with the latest kernel, compiler toolchain, GNOME/KDE, X and OpenOffice versions?

Re:Anhy reasons not to? (-1, Offtopic)

Anonymous Coward | more than 6 years ago | (#23418898)

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

Novell= Microsoft
Microsoft= Evil
Evil= anti-Ubuntu

Diversity is Stronger (5, Insightful)

Doc Ruby (173196) | more than 6 years ago | (#23419298)

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:Diversity is Stronger (3, Insightful)

Laur (673497) | more than 6 years ago | (#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:Diversity is Stronger (2, Interesting)

Doc Ruby (173196) | more than 6 years ago | (#23420834)

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 or inclusions from the last significant release of any distro.

Many more people probably do so at the even finer granularity of unofficial updates to existing installs, but that's not the same as getting an official release, with all its support, and even with support contracts (like with the distros Shuttleworth is talking about). Which is why we're talking about the actual release schedules, because unofficial updates are so frequent and self-organizing that they don't need to be synchronized. It's the value of the full, supported (and tested) releases that Shuttleworth and I are talking about.

Re:Anhy reasons not to? (4, Insightful)

RiotingPacifist (1228016) | more than 6 years ago | (#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:Anhy reasons not to? (3, Insightful)

billcopc (196330) | more than 6 years ago | (#23420448)

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.

Components - yes. Distributions - no. (3, Insightful)

khasim (1285) | more than 6 years ago | (#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?

Re:Components - yes. Distributions - no. (4, Insightful)

bcmm (768152) | more than 6 years ago | (#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:Components - yes. Distributions - no. (5, Insightful)

Random BedHead Ed (602081) | more than 6 years ago | (#23419412)

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

Re:Components - yes. Distributions - no. (1)

hairyfeet (841228) | more than 6 years ago | (#23421188)

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

Yuck (3, Insightful)

SatanicPuppy (611928) | more than 6 years ago | (#23418768)

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 (4, Insightful)

zappepcs (820751) | more than 6 years ago | (#23419068)

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

mweather (1089505) | more than 6 years ago | (#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:Yuck (1)

hawk (1151) | more than 6 years ago | (#23419880)

Debian will.

Oh, they're not "waiting". My bad . . . :)

hawk

Re:Yuck (1, Insightful)

Anonymous Coward | more than 6 years ago | (#23421224)

So basically exactly like what we have already.

Good luck with that (4, Insightful)

mlwmohawk (801821) | more than 6 years ago | (#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.

Re:Good luck with that (1)

BrainInAJar (584756) | more than 6 years ago | (#23419818)

Linux was never part of the UNIX wars. Linux is not UNIX.

The LSB is a counter-example and a way forward (5, Insightful)

g2devi (898503) | more than 6 years ago | (#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 (2, Interesting)

mpapet (761907) | more than 6 years ago | (#23420520)

There's absolutely nothing reasonable about Shuttleworth's request.

1. It's a Trojan Horse to legitimize Shuttleworth's business prospects. Simultaneously he'll out-shout Debian and give him a platform with which to more easily compete with Novell. Given Novell's history of mismanagement, I'd say they are helping him already.

2. There will be _lots_ of ubuntu users ready to mod me down for comment #1. Let's entertain the notion that I am completely misguided and I fall in line with the Ubuntu groupthink. What exactly would be accomplished? Nothing. Ubuntu already forks from Debian early on and as far as I can tell, never the twain shall meet.

3. Debian still releases when ready. Ubuntu releases on a calendar, warts and all. Imagine if the Debian community fell under Shuttleworth's and changes to a firm "ready or not" release schedule. It would slowly turn the Debian project into Shuttleworth's fiefdom rotting it from the inside.

Effect on testing? (2, Interesting)

Anonymous Coward | more than 6 years ago | (#23418778)

Simultaneous release schedules = simultaneous betas = testers spread more thinly.

Re:Effect on testing? (4, Interesting)

Cryophallion (1129715) | more than 6 years ago | (#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.

Re:Effect on testing? (1)

ketilwaa (1095727) | more than 6 years ago | (#23419510)

Aren't Ubuntu users more likely to betatest Ubuntu, SUSE users SUSE, etc? That's the way I'm doing it. That way you get the total amount of testers up, the only difference is you get them within the same time frame.

Matching toolchains, binary compatible apps (2, Interesting)

visualight (468005) | more than 6 years ago | (#23418782)

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.

Re:Matching toolchains, binary compatible apps (1)

ricegf (1059658) | more than 6 years ago | (#23419582)

You mean like cnr.com [cnr.com] ?

This idea TOTALLY SUX! (2, Insightful)

trolltalk.com (1108067) | more than 6 years ago | (#23418796)

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.

Re:This idea TOTALLY SUX! (5, Insightful)

teslar (706653) | more than 6 years ago | (#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:This idea TOTALLY SUX! (3, Insightful)

trolltalk.com (1108067) | more than 6 years ago | (#23419274)

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:This idea TOTALLY SUX! (2, Insightful)

ketilwaa (1095727) | more than 6 years ago | (#23419610)

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:This idea TOTALLY SUX! (1)

pxc (938367) | more than 6 years ago | (#23419558)

I don't switch distros so much as add distros, but I do it pretty often. Usually if there's a new release of a distribution I've enjoyed or heard about, or one I've been excited about but disappointed in, I'll download it and install it to a VM. If I like it, I promote it to my HDD. I don't really feel any distro loyalty and I find it really fun to try weird distributions or new ones. The only thing I don't do often is try Gnome-based distributions.

At the moment, I'm really excited about trying GoboLinux, since it abandons the rather antiquated Linux file system for something that may be better.

Re:This idea TOTALLY SUX! (0)

Anonymous Coward | more than 6 years ago | (#23420550)

I switched from opensuse to debian to ubuntu; the first thing that came to mind for me with this proposal is the confusion that might result with basic users who don't know the difference between .rpm and .deb packages. It's not like they're going to know how to use alien, or know how to deal with the problems with their system that might result.

This is probably not a huge problem, and I honestly don't know how well basic users do with installing the correct packages for their distros now. I assume many of those users never change their repos and just install everything via synaptic or yast etc. so maybe similar release schedules wouldn't prompt a user to download an opensuse .rpm and try to install it on ubuntu, for example. But I still think that this is something to be careful about; perhaps better education on the subject for new users is needed.

Re:This idea TOTALLY SUX! (0)

Anonymous Coward | more than 6 years ago | (#23419830)

I disagree with your first point. My plan is to try to do a full reinstall on every major ubuntu release (lts) for housecleaning, and knowing other linux users I'm not alone, I only use "upgrade" for the minor releases. If I were to have to choose between all the other brand spanking new major releases at this time I would be more likely to switch distros. If switching to fedora meant having to install a release that was older, I wouldn't (and don't) switch.

Still mulling the security aspect of it all....I suspect that inclusion policies would keep too much syncronization from happening.

Re:This idea TOTALLY SUX! (0)

Anonymous Coward | more than 6 years ago | (#23420358)

This is not intended for the community editions. This is for the long term editions where people buy support. There is likely little migration from on distribution to another, or even a different OS, without a great deal of consideration first. The real benefit here is when a bug is found in a package, be it the kernel or something like GNOME or KDE, three years from now. That is five or six versions of Gnome out of date. With a coordinated set of primary applications at least the major LTS distributions can maintain their patches together. Here even Debian's release cycle is not an issue sine the idea is that support is for up to five years, not six months for the community editions.

Re:This idea TOTALLY SUX! (2, Insightful)

PHPfanboy (841183) | more than 6 years ago | (#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.

Good idea... (1, Flamebait)

carrett (671802) | more than 6 years ago | (#23418806)

but unfortunately Shuttleworth isn't the boss of Linux and other Linux people might (read: probably will) take offense to his trying to be the great leader of what is undoubtedly a good idea.

Re:Good idea... (2, Informative)

Rudd-O (20139) | more than 6 years ago | (#23419066)

Didja even read the fucking article? He's NO WAY EVEN CLOSE to acting like the boss of Linux.

Re:Good idea... (2, Informative)

Steve Max (1235710) | more than 6 years ago | (#23419156)

Why should other distros adapt to Ubuntu's timeframes? Fedora is already in a 6-months schedule; OpenSUSE releases aren't time-based but feature-based; Mandriva has their own 6-month schedule; and so on. It works for them. If Shuttleworth is so keen on having synchronized releases, he should move the next Ubuntu to match, say, the next Fedora. This will give him and the users the benefits he wants without needing any interproject discussion.

Re:Good idea... (3, Informative)

TLZ9 (1194305) | more than 6 years ago | (#23419326)

RTFA

"If two out of three of Red Hat (RHEL), Novell (SLES) and Debian are willing to agree in advance on a date to the nearest month, and thereby on a combination of kernel, compiler toolchain, GNOME/KDE, X and OpenOffice versions, and agree to a six-month and 2-3 year long term cycle, then I would happily realign Ubuntu's short and long-term cycles around that."

He's explicitly writing that he would adapt his Ubuntu's release to a date set by others.

Re:Good idea... (4, Insightful)

ricegf (1059658) | more than 6 years ago | (#23419680)

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.

Re:Good idea... (1)

thetartanavenger (1052920) | more than 6 years ago | (#23420866)

Wow, I knew slashdot was famous for users never reading the article, but I at least thought they'd read the summary!!

Distro differences (2, Insightful)

IBBoard (1128019) | more than 6 years ago | (#23418834)

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?

dream of true free software syncronicity (1)

wiredog (43288) | more than 6 years ago | (#23418842)

Penguinicity!

syncronicity [sic] (1)

smitty_one_each (243267) | more than 6 years ago | (#23419618)

Many miles away
Something crawls from the slime
At the bottom of the dark
Lake XacuabÅ

Re:syncronicity [sic] (1)

smitty_one_each (243267) | more than 6 years ago | (#23419662)

Bollocks. Should be:
Lake Xacuabs (with a wee vee atop the 's')
If only they had synchronized the distros.

err Gentoo? (5, Funny)

xav_jones (612754) | more than 6 years ago | (#23418856)

I use Gentoo, you insensitive clod!

Re:err Gentoo? (3, Interesting)

crow (16139) | more than 6 years ago | (#23419072)

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

Tanktalus (794810) | more than 6 years ago | (#23420592)

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.

Re:err Gentoo? (5, Funny)

mweather (1089505) | more than 6 years ago | (#23419180)

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

One reason why Synchronicity is bad (4, Informative)

Dystopian Rebel (714995) | more than 6 years ago | (#23418864)

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

Re:One reason why Synchronicity is bad (4, Funny)

KokorHekkus (986906) | more than 6 years ago | (#23419060)

We learn something every day. I learned that Jung had a term called synchronicity.

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]

Maybe do it in reverse? (5, Insightful)

bsDaemon (87307) | more than 6 years ago | (#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

Re:Maybe do it in reverse? (1)

cbart387 (1192883) | more than 6 years ago | (#23419324)

Agreed, working with Fedora sounds good because both Ubuntu and Fedora are on a 6-month release cycle. Granted, Fedora is a little more loose with their release date. It's not as set in stone as Ubuntu. But even having them within the same week would be easy (I would think) to accomplish.

agree to a six-month and 2-3 year long term cycle
The only fly in the ointment is that it sounds like Mark would like to see a 2-3 year long-term support release from the other distributions. I just don't see Fedora doing that. Their whole shtick is being on a the forefront of development. Doing a long-term support would be counterproductive. This is especially true since users can always use CentOS or Redhat for long-term support.

Kaizen (2, Insightful)

Polski Radon (787846) | more than 6 years ago | (#23418894)

I'd prefer having OSS projects follow the Kaizen constant improvement process than having the project built to order for a given deadline.

Makes enough sense to me. (1)

davolfman (1245316) | more than 6 years ago | (#23418918)

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 (2, Insightful)

dbc (135354) | more than 6 years ago | (#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:Loony idea (0)

Anonymous Coward | more than 6 years ago | (#23419104)

I don't see how this proposal would prevent anyone from making or using a rolling-release distribution. So, all that's left of your post is that you don't like Ubuntu. I'm sure this will be hard to believe, but nobody cares.

Re:Loony idea (2, Insightful)

Anonymous Coward | more than 6 years ago | (#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).

Re:Loony idea (2, Insightful)

myvirtualid (851756) | more than 6 years ago | (#23419320)

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.

Re:Loony idea (0)

Anonymous Coward | more than 6 years ago | (#23419518)

Umm... you could just uninstall the unsupported packages, then install new ones afterwards. Dependency tracking is the wonder and magic of APT, and you would get that with any sane distro.

Re:Loony idea (1)

myvirtualid (851756) | more than 6 years ago | (#23421316)

Umm... you could just uninstall the unsupported packages, then install new ones afterwards. Dependency tracking is the wonder and magic of APT, and you would get that with any sane distro

Good idea, and maybe that will work in my case...

...unless the package isn't part of the distro. Like I wrote, I haven't investigated, because having an operational server that does what I need is more important right now than upgrading. It's a priority thing. (Just for fun, I checked packages.ubuntu.com and hylafax is there, so it probably isn't hylafax blocking me.)

What else do I have on this box? Hmm, let's see, I set it up when Dapper was released, added a couple of things I wanted - and I'm pretty sure not all were APT-based - and haven't really touched it since. So, no, I don't remember. It works, I leave it alone, we get along great.

:->

Great Idea (4, Insightful)

MrMunkey (1039894) | more than 6 years ago | (#23418980)

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.

Will increase the size of the GNU/Linux pond (1)

DFJA (680282) | more than 6 years ago | (#23419608)

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 idea is well worth a punt. If it doesn't work out, there's the option of not repeating it.

However I'm not convinced that RHEL and Debian are similar enough in their priorities for it to work well with them. They both deliberately choose older (hence more stable, better tested) versions of software. Ubuntu is better aligned with OpenSuse, Fedora, Mandriva and a large number of the more minor distros (PCLinux OS, Mint, Mepis etc.).

Translation? (4, Insightful)

nine-times (778537) | more than 6 years ago | (#23419010)

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? (5, Interesting)

NMerriam (15122) | more than 6 years ago | (#23419192)

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.

Re:Translation? (1)

xant (99438) | more than 6 years ago | (#23420004)

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 that with the recent openssl whammy, and Hardy is starting to stink up the joint a bit.

Now, take all that with a grain of salt: I'm running Hardy, and I'm pretty happy with it apart from needing to manually install firefox 2.

Nevertheless, Shuttleworth really wants major application developers to sync up with *him* so that e.g. Firefox 4 comes out BEFORE Ubuntu 9.04 (or whatever) rather than after. This olive branch to the other distro vendors is an attempt to manipulate that. I think it will fail just because he's trying to herd cats, but I can't blame him for trying.

Re:Translation? (0)

Anonymous Coward | more than 6 years ago | (#23420288)

I think that's about right. I develop a few software packages that are included in various distros. It can be difficult trying to develop for distros that come out at different tims with different versions of the required libraries. If Fedora, Ubuntu and a few others (openSUSE, for example) were all on the same cycle, it would make my develop go smoother.

It would certainly save me from going "Wait, Ubuntu has version 4.2 and
Fedora has 4.1, but Fedora has a release next month with 4.3...."

I'm definitely for it (1)

erroneus (253617) | more than 6 years ago | (#23419064)

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 find, is just as annoying. They have Firefox 3 beta and a pre-release version of X.org. What's wrong there? Well, I don't mind the Firefox 3 thing so much... but the X.org thing is a problem because nVidia doesn't have a compatible driver ready yet. So I can't really go to Fedora9 until that is resolved. This reminds me of why I switched away from ATI in favor of NVidia... they were always quicker with the driver releases. But you can't really blame NVidia in this case. It's a pre-release version of X.org after all!

But if we had a 3 or 4 times per year "sync holiday" or something, I think it would give a pace that everyone could work with.

Re:I'm definitely for it (3, Informative)

tobiasly (524456) | more than 6 years ago | (#23419826)

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

What about the load on the servers? (5, Insightful)

knorthern knight (513660) | more than 6 years ago | (#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.

Re:What about the load on the servers? (1)

FudRucker (866063) | more than 6 years ago | (#23419266)

I wish I had mod points, Bump parent up +5 Instightful!

Re:What about the load on the servers? (5, Insightful)

stormguard2099 (1177733) | more than 6 years ago | (#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

Re:What about the load on the servers? (1)

garett_spencley (193892) | more than 6 years ago | (#23419732)

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:What about the load on the servers? (2, Insightful)

shadylookin (1209874) | more than 6 years ago | (#23420722)

That's all well and good for people whose ISPs aren't throttling bittorrent traffic. Some of us however would just be screwed.

Re:What about the load on the servers? (1)

RobBebop (947356) | more than 6 years ago | (#23419778)

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.

Re:What about the load on the servers? (1)

knorthern knight (513660) | more than 6 years ago | (#23420506)

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 are GNOME and KDE and gcc and Xorg. While I use Blackbox WM, there are quite a few apps that use the base libs of GNOME and KDE.

Re:What about the load on the servers? (1)

slaingod (1076625) | more than 6 years ago | (#23421222)

Yes, but you won't be competing against all of the people who ARE using bittorrent. And if direct download times are really that bad, maybe your throttled bittorrent would still be faster :)

Re:What about the load on the servers? (1)

r_jensen11 (598210) | more than 6 years ago | (#23421220)

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.

Please keep free software PHB free (3, Insightful)

Anonymous Coward | more than 6 years ago | (#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.

big change for ubuntu (1)

ajayrockrock (110281) | more than 6 years ago | (#23419218)

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:big change for ubuntu (2, Informative)

ricegf (1059658) | more than 6 years ago | (#23419852)

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

One small step (1)

Dcnjoe60 (682885) | more than 6 years ago | (#23419992)

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 the big players in the field, could have taken the approach that "We release every April and October, the rest of you should release in those months, too." Instead, they are saying "Look, it would be great if we could coordinate our release schedules so we could all benefit for these reasons. It would be such a benefit the linux community as a whole, that I'm willing to change Ubuntu's release schedule to accommodate the rest of you if that would help in getting this going."

So to paraphrase Neil Armstrong, this is actually just a small step for Ubuntu, but a giant leap for the Linux Community.

Bad Bad Idea I Think (2, Insightful)

immcintosh (1089551) | more than 6 years ago | (#23420030)

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! (2, Informative)

Builder (103701) | more than 6 years ago | (#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.

Developers, Engineers etc (1)

Bullfish (858648) | more than 6 years ago | (#23420146)

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

Linux a common goal, good software. (0)

Anonymous Coward | more than 6 years ago | (#23420196)

The more they can work with each other the better. It only makes things easyer for all. A little open standardizing would be great for example package management. A universal package installer would be nice. Just as long as each distros identity stays intact.
Then we have that ugly little Device driver issue. I think standardizing device drives across distros would make some vendors more likely to work with the community.

Please elaborate... (0)

Anonymous Coward | more than 6 years ago | (#23420212)

To be align with the idea, I'd like to propose:
- Synchronize the distribution names (subuntu, rhubuntu, dubuntu, etc)
- Synchronize the package management also (hmm, deb?)
- Synchronize the companies - do we really need that many? They release at the same time, they release the same software. One should be enough, let's call it Canonical Ltd, since it already has the ubuntu trademark.
- Result: GNU/Linux == *ubuntu

One explanation (2, Interesting)

jalefkowit (101585) | more than 6 years ago | (#23420228)

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.

Would never work for Debian (3, Insightful)

Nimey (114278) | more than 6 years ago | (#23420472)

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.

This is all crap (0)

Anonymous Coward | more than 6 years ago | (#23420708)

Release software when it's ready(and god willing, after a lot of QA).
If it's after a distro went out the door, make a robust update utility.
Oh wait, we already have those...

Possibly good, possibly bad.. (1)

Kjella (173770) | more than 6 years ago | (#23420818)

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

Lets see (2, Funny)

whitespiral (941984) | more than 6 years ago | (#23420894)

With most distributions having simultaneous releases, their users would suck the bandwidth out of ISPs dry, leaving the US, possibly the world, with modem-like connection speeds. MS would call for a ban on Linux distros as a matter of national security, slip a few congressmen a suitcase full of green bills, and suddenly, Linux is the newest technological outlaw. Lovely, Shuttleworth. Shuttle the fuck up.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?