Slashdot Mirror
Shuttleworth Calls For Coordinated Release Cycles
voodoosws points out on Mark Shuttleworth's blog Shuttleworth's call for synchronized publication of Linux distributions, excerpting: "There's one thing that could convince me to change the date of the next Ubuntu LTS: the opportunity to collaborate with the other, large distributions on a coordinated major / minor release cycle. If two out of three of Red Hat (RHEL), Novell (SLES) and Debian are willing to agree in advance on a date to the nearest month, and thereby on a combination of kernel, compiler toolchain, GNOME/KDE, X and OpenOffice versions, and agree to a six-month and 2-3 year long term cycle, then I would happily realign Ubuntu's short and long-term cycles around that. I think the benefits of this sort of alignment to users, upstreams and the distributions themselves would be enormous. I'll write more about this idea in due course, for now let's just call it my dream of true free software syncronicity."
Seriously, this would be a boon for Linux development in general, filling in the big gaps left by the LSB.
- None can love freedom heartily, but good men; the rest love not freedom, but license. -- John Milton
I see the attraction of having the latest releases of KDE and GNOME and so forth.
But I'm not seeing why the other distributions matter that much to Ubuntu's release schedule.
The more items you have to sync, the more difficult it gets to be. Is Ubuntu really going to wait for KDE to wait for SuSE to get GNOME compiled with the latest GCC?
I can't imagine multiple development teams running under completely different chains of command syncing their release cycles. What happens when one runs behind? Does it delay the rest?
I can see the benefits with regards to the software that is common to most linux distros, but I can't see all those companies ever working together that closely.
ad logicam Claiming a proposition is false because it was presented as the conclusion of a fallacious argument.
Here we have a perfectly reasonable proposal that would help a whole segment of the industry and it has a snow balls chance in hell.
The UNIX wars never stopped, BTW, it is just that major components under Linux have been independently developed.
Simultaneous release schedules = simultaneous betas = testers spread more thinly.
First thing I thought of is being able to mix repos of several distributions. I don't think RH and Novell will do it, just for that reason.
Samsung took back my unlocked bootloader because Google wants me to rent movies. They're both evil.
All this would do is ensure that people stick with their current distros. After all, if they all come out on the same date, you're going to grab the one you're currently using, and upgrade. Then you won't have as much incentive to try another one that came out on the same date, since you just finished the upgrade, and they'll all most likely have the same features.
On the other hand, having different distros purposefully unsynchronized allows for new features to be introduced and widely disseminated one distro at a time, so if there's a security or other problem, it doesn't affect almost everyone from day zero.
So, not only is the proposal anti-competitive, it's inherently insecure.
Kevin Smith on Prince
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.
I'm against picketing but I don't know how to show it.
It will slow down development progress, reduce competition between distributions. If Ubuntu, RedHat or Suse are unable to keep up with each other then they fall by the wayside, that's the nature of a competitive market.
Deleted
So what will be the distro differences? I thought "how to update the packages are" was one of the decisions people made. Surely synching with Debian would put everyone's schedule back a bit and be a bit pointless since they're not likely to be using the same versions of things.
Also, would it really help upstream? If everyone is going for the same dates then surely upstream will have periods when feedback is at a low because everyone is focussing on assembling the final distro and the integration?
Penguinicity!
Best Slashdot Co
I use Gentoo, you insensitive clod!
"Synchronicity" is a term invented by Carl Jung and made popular by a pop-music band with a singer whose irritating high voice keeps listeners awake when his dreary pretension threatens to put them to sleep.
Unless he is addressing the famous Ro-o-o-o-oxanne, Mr Shuttleworth may mean "synchronization" or "synchrony".
Rich And Stupid is not so bad as Working For Rich And Stupid.
Leave Debian out of this for the moment, because it seems to take them a few years to get a major release out the door...
Instead of getting commercial Red Hat and SuSE on board, why not get Fedora, which feeds into RHEL, on board first?
Ubuntu and Fedora just put out releases within a month of each other, so it wouldn't take much to keep the schedules synced from on out. Maybe get some other popular community distro on board next.
RH will probably fall into step by default, which would be nice (i guess -- i can't buy it at the store anymore, so wtf do i care what they do?) then.
trying to get the free-be to dictate to major corporate distros that have been around for a hot minute is not likely to happen. imho
I'd prefer having OSS projects follow the Kaizen constant improvement process than having the project built to order for a given deadline.
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.
A key differentiator among Linux distros is package inclusion policies and release policies. Some people like Ubuntu because it has "stable" packages -- I can hardly stand Ubuntu because it has stale packages. I prefer rolling-release distros -- Shuttleworth's idea doesn't even have a translation into that world.
Choice is good. Package QA and selection policies are a big part of what drives the choice.
Hey, Mark: NAK Reject
I think this is a great idea from the perspective of people who currently do not use Linux. From their view point they see Windows, Mac OSX, and Linux. They don't know that there's Debian, RedHat, SuSE, Ubuntu, etc., nor do they care. If the release schedules are at least somewhat in sync, then each distribution should be using the same, or close to the same, kernel, library and program versions. The only differences between them would then be the distributions' customizations of those packages. In my opinion I think that it could help to bring Linux to be a bit more mainstream and be more competitive, at least in the desktop market. However, I do think that it should be a consensus among groups rather than having one "master" directing everything. The idea just would not work that way.
I also think it would be a good idea from the current Linux users' perspective as well. It would make it easier to compare distributions head-to-head.
So I'm not sure I understand the big idea here, but let me give it a shot. Shuttleworth is suggesting that if the big distributions all synchronized their releases, it would set clear targets for the upstream developers, e.g. the people at OpenOffice could say, "Let's be sure to get a new release ready for all the November '09 Linux distribution releases."
So it would start a sort of natural schedule for developers to work on stabilizing their projects at regular intervals... or something like that. Is that what he's getting at? Am i close?
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.
Many universities and other publically-spirited sites mirror several distros. Different release cycles spread out the load on these servers. Having multiple distros being updated at once will result in more people updating at the same time. The result would be servers sitting almost idle for periods of time, with short periods of "server not available".
This is not a joke. I remember, years ago, when Redhat was *THE* major end-user distro. When a new version came out, regular users would have to wait a week or so before they could download it.
I'm not repeating myself
I'm an X window user; I'm an ex-Windows user
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.
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.
Nerd rage is the funniest rage.
huh? Isn't he just asking all the other distro's to adapt to ubuntu's release schedule?
Yes: the different release schedules mean that in nearly any given month, I can turn to a different distro for a full release, tested by their independent beta populations, without waiting for the "synchronized Christmas".
I understand that synchronization will make Shuttleworth's life easier, on the supply side. But it will reduce the diversity in the Linux ecosystem. People will not have switching opportunities between different distros when they want to get a new complete (and supported) release before their current distro's is ready. Which might be good for Shuttleworth, with the dominant market share, but it's not good for anyone else.
Which is why I think the other distros won't go for it. And why I'm happy about it.
The Cathedral is obsessive about monopolizing the calendar. But in the Bazaar, we can each have whichever calendar we want, with machines to translate among them.
--
make install -not war
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.).
43 - For those who require slightly more than the answer to life, the universe and everything.
Many miles away
Something crawls from the slime
At the bottom of the dark
Lake XacuabÅ
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
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.
I'd really rather see projects like OpenOffice, KDE, GNOME, X, etc., get released on a "when it's ready basis" than seeing them all bending to the collective will of the major Linux distributions. Once Ubuntu et al. all decide they want October release dates or whatever, I imagine major projects will start getting pressured to conform as well, regardless or whether or not it makes any SENSE for them to have their releases at that point.
For a Linux distro (assuming you don't use a rolling release system which I personally prefer), it makes sense to have regular dates where you update your system to all the latest. The only "benefit" I could see coming out of a synchronized release cycle is to pressure projects to conform to that cycle too--otherwise what's the point--and for projects like OpenOffice that sort of thing just doesn't make any damn sense. Add to that the additional bureaucratic layers and inefficiency introduced by having to coordinate even more stuff...
I for one hope this falls flat.
I can definitely see how this would be of major benefit to all Linux users who don't use SLES or RHEL. By having a synchronised release, there would be a better chance of major libraries like glibc and compiler versions being in-sync. This would increase the chances of getting ISVs to support something other than just RHEL or SLES which is mostly the current case for large software apps.
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"...
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.
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
I'm surprised that nobody yet has mentioned the most obvious reason why Shuttleworth would want this.
Canonical shipped shipped their latest Ubuntu release, 8.04 ("Hardy Heron"), last month. Canonical wanted Hardy to include Firefox 3 instead of the getting-a-bit-long-in-the-tooth Firefox 2. However, since Mozilla's release target for FF3 was a month after the release target for Hardy, Ubuntu had three choices, none of them ideal: put off the move to FF3 for the next release (six months down the road), ship Hardy with a beta version of FF3, or delay shipping Hardy until FF3 had shipped. They ended up shipping with Firefox 3 Beta 5.
This matters because Hardy is a so-called "Long Term Support" (LTS) release, which Ubuntu commits to supporting for eighteen months instead of the standard six (for customers who don't want to be updating their OS every six months). So now Canonical is on the hook to support a beta release of Firefox until long after FF3 final is released and the betas are forgotten.
I would presume that Shuttleworth wants coordination in distro release cycles because it would give him more leverage with third parties in situations like this. If Canonical says to Mozilla "hurry up and finish FF3 so we can make our release date", that's easy to ignore because it's just one distro. If EVERY distro is saying that to Mozilla, they'd be more inclined to listen -- and probably more likely to orient their own release cycles to fit with those of the distros.
Read my blog.
You're forgetting the Linux Standards Base.
Ubuntu, Debian, Red Hat, SUSE, and others already agree to shipping the LSB for some time now.
If at least three of these can agree to ship the same LSB version at approximately the same time, they won't be doing anything new, but they could gain the benefit of sharing bug reports, sharing device drivers (since a standard kernel would be the focal point for driver development), even sharing management tools (since they all assume the same LSB version), and better support from 3rd party proprietary products like Flash, Oracle, and VMWare (which still hasn't shipped a working version for the Ubuntu LTS kernel). Granted, the last point might cause, FSF devoties to throw fits, but unfortunately some of us wouldn't be able to move to Linux without these products (e.g. I use Oracle at work and my wife needs VMWare to access some windows specific functionality on her bank that crashes KVM and VirtualBox and does not work at all in WINE).
Given that the LSB already exists, I see little downside in taking this one step and lots of upsides.
Debian's organization would have to make a major fundamental change to stick to an actual release schedule. They have /never/ been on time for a release, preferring to wait until enough of the packages don't have release-critical bugs.
I could maybe see it working for a more commercial organization like SuSE, but not for an all-volunteer effort like Debian.
Hail Eris, full of mischief...
E pluribus sanguinem
There's absolutely nothing reasonable about Shuttleworth's request.
1. It's a Trojan Horse to legitimize Shuttleworth's business prospects. Simultaneously he'll out-shout Debian and give him a platform with which to more easily compete with Novell. Given Novell's history of mismanagement, I'd say they are helping him already.
2. There will be _lots_ of ubuntu users ready to mod me down for comment #1. Let's entertain the notion that I am completely misguided and I fall in line with the Ubuntu groupthink. What exactly would be accomplished? Nothing. Ubuntu already forks from Debian early on and as far as I can tell, never the twain shall meet.
3. Debian still releases when ready. Ubuntu releases on a calendar, warts and all. Imagine if the Debian community fell under Shuttleworth's and changes to a firm "ready or not" release schedule. It would slowly turn the Debian project into Shuttleworth's fiefdom rotting it from the inside.
http://www.maxineudall.com/2010/02/should-economists-be-sued-for-malpractice.html
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...
...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.
Live today, because you never know what tomorrow brings
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.
I thought GNU's not Unix. /ducks
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.
May I start this post that I'm using Ubuntu and loving it. I also appreciate Shuttleworth's commitment that there are no two different versions (paid or community), but I'm sensing that this proposition could very well be an "Embrace Extend and Extinguish" strategy in disguise.
In the past year Linux has been getting a lot of more attention from the press than in the past. Ubuntu's simplicity and rapidly spreading user-base has been one major factor, along with Asus' eeepc warm reception and the decision of many software & hardware corporations to better support open source (such as ATI's new-found open source zeal, VIA's release of linux drivers, etc)
Now, it happens to be that the distro that gets the most press hype is Ubuntu. If the release of every major distro is synched, then we will see simultaneous reviews of all distros, with the press usually favouring (both in article real-estate and disposition) the most popular distro, especially the one that is the most wide-spread and allegedly the most user-friendly of them all. That will shroud the other distros behind the veil of unfair press coverage, just the way that it happens with Microsoft's products, who get undue attention and favouritism because of their popularity and dominance in the market. If distros release-dates are independent of each other, then every one gets their (quasi) equal chance of fair press coverage, which gives every distro a chance become the top one through innovation.
To clarify, think about this scenario:
All the distro release dates synchronise. Ubuntu gets the most press coverage (benefiting from the fact that this date is a milestone for the linux world, since EVERYONE releases at the same time) Hence, more users opt for the press' poster child, making the other distros lag behind in terms of user-base. Do you see the vicious circle? When ubuntu becomes dominant enough, it can absorb or strangle the other distros solely by the fact that in the minds of the users, ubuntu IS linux. Imo, that would hurt the huge range of choices that make linux what it is.
I suppose it could be that Canonical never thought of this, but I don't really believe that the top-notch company in the Linux world in terms of marketing hasn't thought of that scenario.
I'm working for an ERP developer. Our product runs on JEE and with the nature of that on all relevant server platforms.
In theory. In practice, one has to test all combo's of java/jboss/os(/db) versions. The way it is now, this is a permanent job.
The proposed distro hardbeat could:
-increase the number of supported platforms because all java/jboss versions are the same;
-reduce the costs because it can be scheduled twice a year;
-increase the market share of linux, because the decision makers trust the platform.
Flying to space is really easy compared to this, good luck, Shuttleworth.
Debian has the best motto; "Release when it's ready". That's the best policy to have imho 'Nuff said
Is this really necessary? Can't they come up with an *easy* (non gentoo/slack/LSF) distro that can just do incremental updates, including the kernel, forever? And when are we going to get "diff" upgrades for the popular apps? Why do we still have to download all brand new browsers every other Wednesday because of some minor security glitch? If you are stuck on dialup (like I am unfortunately right now, come on wimax!) it has gotten insane. I've been bounced from two different fairly well known isps for excessive use because of having to resort to every dang night all night long apps upgrades, day after day after day, and that is without full kitchen sink installs. Then six months later, you've just finished upgrading everything and wham, another stupid release. Crazy. Why can't they do just incremental releases, really, what is the technical reason for having all "new" releases? How much of the code really changes as opposed to mostly the same code with a different version number in the header?
Any effects that make multiple distros a 'smaller attack vector' for malware are the same exact effects that make multiple distros that much harder to target for ISV's.
Cute way of taking a liability and spinning it into an advantage. But there are other ways (address randomization, etc) to shrink the attack vector without making the good guys jump through hoops.
Build it yourself Slashdotters will always pooh-pooh calls for harmonizing distros. Folks like Shuttleworth, who'd like to eventually build a moneymaking business around Linux, know why it's a good idea (for them, at least). And they're the ones, if anybody, that are going to get Dell and HP to preload their distros. So it's eventually gonna be that the commercial distros are the only ones targeted by ISV's and the rest of us won't get workable plugins, etc. Or the rest of us will sync with the commercial distros. Or Linux will never be mainstream - I guess I can live with that, at least until any developers who want it to be mainstream start giving up...
Posted from my Android phone. Oh, I can change this? There, that's better...
You and I have different standards for an OS that is "ready."
Everyone knows that debian stable is almost never released
Who is this everyone you speak of? September of this year Lenny turns stable.
The developers of say, KDE or Firefox would know that if they can get their new versions done at release-time they'll have the new versions in all distros as soon as possible.
That is asking waaay to much of most projects. Shuttleworth knows this tilts the loosely-knit relationship between distros and the projects they package to the distro's advantage. It is a dangerous precendent that puts too much decision making power into the hands of a couple of distros. The loosely knit relationship between the projects works to everyone's benefit. Mark, being a business guy, likes command & control. Which, will screw the OSS community over badly.
Now the distros sometimes have to ship beta-versions, stay with the old one, or delay the release for an unknown period of time.
I would argue the distro maintainers are the ones to blame for choosing beta quality packages.
If the base components of all distros, openoffice, gcc, etc, can attend this common release cycle, the savings related to the combined testing time can be allocated to improve new features that will improve each distro uniqueness.
The differentiation should be in new capabilities and reliability, and not in who has the new software version of that package.
Use this opportunity to improve the things that are not common between distros!
Math is beautiful... e^(pi*i)+1=0
M.S. (oops!) and the *buntu guild of piggybackers hereby declare Debian their mule while proposing to RedHat and Novell to divide the pie and then take it eeeeasy. What if RH and novell say yes... two out of three.
Debian of course has its own release cycle and it's not going to change. This whole thing sounds like a bit of a threat IMHO.
If I were debian(ite) I would feel uneasy about this.
Yes, but I have found that new versions of software often have bugs in them. Sometimes causing system failure.
If Suse or RH want to hold back on a new release or RH wants to jump up and be the beta tester for a new version then more power to them. I think that while Shuttleworth may be well intentioned, it would ultimately be a disservice to the linux community for multiple reasons. Security and reliability being the number one reason.
I really think Shuttleworth knows this and is making this statement more to get advertising for his distro than for anything else.
RH and Novell have large customers and are well acquainted with their needs. If in the process they find that certain packages cause problems, they may postpone a release. RH and Novell accepting a release cycle plan based on the communities "We just want to know" or "I have a dream", just isn't going to be a good business decision at this time. And I don't think it makes sense for the Linux Community as a whole either.
I actually stumbled across this last night on firehose or something. No comments had been posted yet and I thought it was a joke along the lines of something in the Onion.
He who said 1,000,000 monkeys on 1,000,000 typewriters would eventually type the great novel, never saw an AOL chat room
Imagine the X.org, Gtk and GNOME release at the same date. You end up with integration issues because Gtk or GNOME were not tested on the latest stable X.org release during the alpha/beta development cycle. and visa versa. From this perspective the total opposite is better.
KDE has historically been able to make incremental releases on time with a 9 month scheme. Now that they are forced to a 6 month scheme some developers find themselves stuck between handling user bugreports and pushing new features before the next period of feature-freeze/bug-fixing settles in. This isn't helping development at all.
Forcing pressure on developers doesn't mean you'll get what you want. In a worse case scenario you're disrupting the eco system and slowing down development instead. Better marketing, worse products. How is that going to help?
The best way to accelerate a windows server is by 9.81 m/s2
maybe Mr Shuttleworth wants to be the Bill Gates of the Linux world.
Anyone else notice his initials are MS?...creepy
Screw trying to 'play nice' with other Linux forks. Approach the BSDers (who have no skin in the 'whos GNU/Lunix version is better' game) and ask 'em.
I think it's a really good idea, since the whole (well, almost) linux community might start to work together. In tandem. On the other hand this might take the edge off the "bazaar" and lead it to a cathedral style of development. I don't know...
"Better marketing, worse products. How is that going to help?"
Isn't that how a lot of software companies work?
He's not suggesting the apps coordinate releases, just the distros.
Sure, that would be ideal to the Ubuntu approach of taking what others do with minimal effort. If done the current way they would need to do give something back and actually do some development upstream, which is of course hard and costly, blogging is free.
I work for a Linux vendor (though I speak only for myself), so take this with a grain of salt...
Personally, I think the staggering of releases between RHEL, SLES, and Ubuntu LTS is *good* for the community, and ultimately the customers as well. If all the enterprise distros synchronized, we'd see a much more pronounced oscillation between adding new features and improving existing code. Currently, someone somewhere is always preparing for a stable release, while someone else has just pushed one out and is addressing the issues that only crop up when customers deploy widely in production, and someone else is in the middle of their life cycle and working on major features they plan to support in their next version. This ensures a constant hum of work on all fronts that keeps community specialists busy in their various areas of expertise, and ensures that hardware and application vendors always have an incentive to post their work as soon as it's ready.
Can you imagine what would happen to the quality of upstream code if developers knew that nobody was going to run it through a heavy QA matrix for the next two years? I shudder to think. Worse, this would draw a much larger distinction between community and enterprise distributions, which might be good for some of the existing enterprise players until new competition comes along and bucks the trend, but would certainly harm innovation, even in the short run. Volunteers may contribute a minority of the lines of code that ship, but their constant involvement in the development process ensures that the enterprise developers don't get too far off track. New software technology always spends time maturing in the enthusiast realm before it gets adopted by the enterprise.
If this proposal is accepted by all of the enterprise vendors, it will lead to forks. Unlike some forks which increase the diversity of research and development, these forks will actually reduce it, because they will draw the majority of the labor away from the innovation and into glorified support.
Linux used to have a stable/unstable release model. It worked for a while, but ultimately it interfered with getting new technology into the hands of the users. We now have the economies of scale that allow us to have frequent stable community releases, with both quality and feature work at every step. We would be fools to give this up.
There's no failure quite as dissatisfying as a complete and total solution to the wrong problem.
Here's a short and sweet description of the development process: Software projects are not just 'latest'. There is a code branch for each release. At some point the people who run the project decide that the current state of the code is what will become the release, and they branch it. Development continues unabated on the 'latest' branch. Development stops and bug fixing starts on the release branch. New features in the release branch that can't be fixed by release time are thrown out (or left undocumented) and saved for the next release. Regressions of course are unacceptable and this is where the sweating and the complaining comes in, because the developers have to fix the bugs before the release date. Most real software projects of course have multiple branches for whatever reason, but you get the idea.
All they are saying is that the distributions want releases to happen at particular calendar dates. This does not restrict development in any way, if the project has decent code management and the developers show some restraint.
Developers don't like this because they are being put to schedule in a job that does not lend itself to following schedules. This is being done for the customer. Commercial software companies work in this fashion. It is a successful strategy, I have seen it employed at several companies.
This is also a really excellent sign, that the body of Linux software is mature enough that someone can make a suggestion like this and have it taken seriously.
A distribution can choose to slow down and only come out once a year, or every 18 months. Hey, look at Debian. Personally I would like something like that for my server. Then its code would NOT be the same as everyone else's. Imagine two releases, each happening yearly, 6 months out of sync. These two releases would have almost no common code between them.
And don't forget that each distribution will patch packages for their own needs. RedHat has many many kernel patches, probably customer-specific, that most other distributions are not going to want. This is just an example, every distribution has to do SOMETHING different, or what's the point?
Lack of diversity doesn't have to be a problem.
Releases do not happen from the latest code. Releases are stable code from a stable branch. They have been through QA. This step needs to happen. The developers can keep on coding, but keep their new code out of the release branch until it is ready to go. This is not limiting at all. Read the title again: scheduled RELEASE cycles, not scheduled CODING cycles.
"It's a Trojan Horse to legitimize Shuttleworth's business prospects"
I have worked for several successful software companies and this is how it works at all of them. The customer wants stable code on schedule and the release process is designed with that understanding. Developers are free to code away on their projects at whatever schedule they work at, but their code stays out of the release branch until it is ready. Welcome to the grown-up world of software development.
I cannot even parse your second point.
"Debian still releases when ready"
Debian doesn't release until GNOME, KDE, and the kernel are ready. Debian does not write these things, they gather them together and get them to work with each other. Nobody is stopping Debian from continuing to do this on whatever schedule they want. Nobody is stopping anybody, or even encouraging anybody, to slow down or change their development plans. What they are asking for is coordinated releases.
And you can put a schedule to it when you make a branch from your stable code. Stop development on the release branch, fix the remaining bugs and it is very much possible to get a release out the door on schedule. The developers keep coding, relatively oblivious to the release process. My employer does it all the time.
Which will put even more (ubuntus runaway popularity is already exerting a lot) pressure on app developers to sync to distro release schedules even if it is destructive to thier other goals.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
Bugs in old code don't matter. Canonical released 8.04 "LTS" with a bunch of known bugs. Several of these were related to the replacement of Gnomevfs and ESD with Gvfs and PulseAudio.
...
/.?
1. Audio locking with Flash or FF crashes with libflashsupport -- your choice of one.
2. Yanking a removable drive without unmounting first leaves the drive mounted and browsable (in cache), but it can't be unmounted and writes fail (of course).
3. F-Spot (now the default photo app) can be run once on 64bit, but GConf entries written on first run cause the app to SIGSEV on subsequent attempts.
The list is enormous. Canonical should have delayed a couple of months just like they did for 6.06, but they were too interested in making their time-table and bragging about it.
If you think I'm off-topic, the timeliness brag is a the beginning of TFA.
By the way, what happened to the ordered and unordered lists on
Put identity in the browser.
Bugs matter depending on their severity, regardless of when they were introduced. My point (and, I believe, the OP) was more that a security problem can be introduced long before it is uncovered and thus end up in multiple versions of a given package, synchronized releases or not.
Nerd rage is the funniest rage.
I phrased that wrong. What I meant is that bugs in old code don't really matter to Canonical. My post was semi-coherent, at best.
Put identity in the browser.
Once again - we see the problem Canonical has: it pays for no up-stream development, so it has no clue how to bug-fix and maintain the packages it ships: so of course it wants to be leaching off another large, professionally maintained distribution wrt. back-ported fixes. As they say - Linux is a team effort: Red Hat develops the kernel, Novell builds the applications, Debian does the packaging, and Ubuntu takes the credit
Software on the GNU/Linux platform is developed independently. The distributions should just grab the latest stable release at the time if they want stability. (Sometimes the cutting edge distributions choose to use beta software which is totally ok - it depends on the particular software project that what their beta means in terms of stability.) Anyway...
Forcing upstream to release a stable release e.g. every six months might not be a good idea at all! The projects might then just release whatever they have at the time and call it stable...
Downstream should probably not dictate the speed of the upstream. That will only weaken the quality of the software.
it doesn't work.
Mozilla already knows what to aim for, and they know they hit badly so they don't even say month (no less date). The say Q1 or Q2, and that is often delayed by half a year or so (look at the Firefox release history and compare it with the RoadMap).
Believing that Firefox 3 would be released a month earlier because Mark Shuttleworth wanted it, is just pathetic, and it shows you (or Mark) have no idea how software development works. IT GETS DELAYED. Even with the most corporate backing it fails by YEARS, look at Vista.
Look at X.org which is silently falling apart, and the features the devs talked about years ago are still just a bright idea with little implementation done.
Mark can try, and hope, that Ubuntu releases will match Gnome releases, but to hope for more than that, is to hope for too much. To "call for" synchronization with projects that have shown to fail RoadMaps by months or sometimes years, and believing they will suddenly release on-time because Mark wants them to, is plain ignorant.
Faster is exactly what this IS about, if you read between the lines. Mark could've released the latest Ubuntu with Firefox 2, no one forced him not to. End of proof. It is about planning ahead. Mozilla team could have planned the 3.0 release date few years ago. They did, the said "2007-2009". That's as exact as they get, and Mark can complain any amount he likes. Mark doesn't really spend much money to pay developers and really help the community. He's leeching more than any other commercial Distro. Redhat and Novell, for instance, spend A LOT on developers and they release MASSIVE amounts of great code. Now, Mark wants them to do it on his demands. For how long will he be able to be credible in the OSS community? He's a monkey, running around, trying to decide things. Planning is one of the worst handled things in OSS, "it is ready when it is ready". That, my friend, is an insult to the customers (users). Insult? Demanding better planning from free-time developers is what's insulting. I agree that some things are way too slow, but I really don't feel insulted. And btw, "customers (users)" should probably just be "users". Most developers of most OSS libraries and tools don't get paid for it. This does not make it easier for proprietary developers only, it makes things easier for every developer. "I know that lib xyzzy will be v. 1.2.3 in every distro so I'll build my exe against it" isntead of "sorry, you cannot build this because your distro has 1.2.2" (and yes, that has happened to me far too often). Oh but cry baby boo hoo, it "happened to you"... And what did you pay? Not a dime.
Wake the fuck up, leecher.
I think that's a very good idea from the creator of Debian.
I really think it needs to be tweaked like having each release every 2 months so people can see what is up and coming for their Distro without having to use a beta.