Advanced

Next Ubuntu LTS in 2010, unless Linuxes synchronize

Posted by Scott_Ruecker on · 9 comments
The Register; By Phil Manchester
Mail this story
Print this story

Mark Shuttleworth, head of Canonical and founder of the Ubuntu project, has called on other Linux developers to synchronize releases of new versions of their distros. He also pledged to deliver the next Long Term Support (LTS) release of Ubuntu, version 10.4, in April 2010 - unless, of course, Red Hat, Novell and Debian decide to co-operate on a synchronized release at a different time.

Full Story

  Nav
» Read more about: Story Type: News Story; Groups: Linux, Ubuntu

» Get new stories by e-mail: nightly or as they are published

« Return to the newswire homepage

  Related stories
» More like this

Comments (9)

Shuttleworth goes on about synchronizing release schedules, yet even his aggressive 6 month short release schedule repeatedly shows how flawed the "Out on target date regardless" schedule is. Bugs that could have been squashed persist across releases as everyone scrambles to get the next one out the door.

Rather I Ubuntu could take on the other Debian approach, that is used by Gentoo/Slackware/others. A perpetual rolling release with stable snapshots every so often so new installs dont have an entire OS to download as update. The rolling release approach would also let Ubuntu finally squash a few of the bugs that have persisted across the last several "stable" releases.
It's not the 6month cycle that's necessarily a problem. It's the release on schedule that is.
I'd go so far as to say it's not the schedule, it's the relative inflexibility at changing the schedule a little to make sure it's right. If there is a show stopper, stop the blasted show.
The Ubuntu release cycle and bug fix mechanism is just as political as Debian's.

The aumix issue where all one had to do was do a recompile was not fixed because the release engineers refused to do so citing policy.

This "meet-the-deadline-or-else" mentality is an issue because bugs are always left in the mix and are reported and worked on by the users. This idea of "release and let the bugs work themselves out" needs to disappear if Canonical ever hopes to get anywhere faster.

Distros like Slackware are only released when they're ready. And it shows. Less bugs are present on some of the distros with a smaller developer base than on the bigger ones with hundreds of developers.

Shuttleworth and others need to focus on making the best distro they can and make the release date of secondary importance.

I'm sure that if a ball park time frame were given most businesses could allow for that. Somehow I do not believe the enterprise will come to a grinding halt because Ubuntu did not release right at the six month mark.

There should be release "windows" and time frames not release dates that are etched in stone.

> I'm sure that if a ball park time frame were given most businesses could allow for that.

I can imagine that six months is a good time frame for hobbyists. Honestly, though, do you know of any businesses that change operating systems every six months? I want to run an OS for _at least_ a year if possible on a work machine, given the cost of something going wrong with the upgrade. I certainly don't have time to identify bugs when I'm trying to get work done. That's why I'm so upset with Hardy - it's not a disaster, but I don't like it and simply don't have time to change it.

If you don't mind a few bugs here and there, why do you need a release at all? Just do like azerthoth says and run a rolling release distro.
Here's another thing. Suttleworth says:

Quoting:"If two out or 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 two-to-three year long term cycle, then I would happily realign Ubuntu's short and long-term cycles around that."


Because he thinks that would improve the quality. I disagree. I think we find and fix far more bugs when every distro uses a different combination of major packages.
bigg

I wasn't implying a release schedule of 6 months for businesses at all. I agree that they would want a far longer time frame of support.

My reference was to a drop dead date that "has" to be met. No matter what the date or time frame, A ball park time frame is better than an April XX, 20XX release date, for example.

A rolling release would bring distros like Gentoo and Arch Linux to the fore. You get more bugs but you do not have to upgrade the whole system just to update an application as is normally done with Debian-based distros. And the resulting bugs from a rolling release cycle usually get fixed in short order.

Maybe the rolling release cycle's time has come.
I'm not sure what are the "benefits to users" that the proponents of synchronised releases talk about. I imagine a vision of a "releasefest" at a specific time of the year ant it scares the hell out of me. I'd rather have total chaos than that. I really hope Debian will not succumb to that, even though some debianistas talk about that (e.g. http://etbe.coker.com.au/2008/05/13/release-dates-for-debian...) citing the Debian Social Contract ("Our priorities are our users and free software").

Post a comment

A free account is needed to post. Write your comment here first: your text is kept in this browser while you sign up or log in, and is waiting for you when you come back.

Your message:
|||||
10
Markdown: **bold**, *italic*, [text](https://link), - lists, > quotes, $x^2$ for math. Formatting help

Sign up and post (it is free)  or  Log in and post