The Art of Release
For those who have not seen it, Mark Shuttleworth's recent
posting is worth a look. He starts with some rather self-congratulatory
talk about the Ubuntu 8.04 release, saying:
To the best of my knowledge there has never been an "enterprise
platform" release delivered exactly on schedule, to the day, in any
proprietary or Linux OS.
One could quibble with this claim in a number of ways, but it is true that
Ubuntu got out a release designed to be supported for a number of years,
and they did it when they said they would. That, of course, is only part
of the job; now they have to follow through on that little promise of
supporting this distribution into 2011. The initial signs
are good: Ubuntu's support thus far has been solid, and it would appear
that the distribution will not be going away anytime soon.
One might well question whether the timely release of 8.04 is noteworthy.
As a community we are increasingly spoiled; an increasingly large number of
projects and distributions manage to get out regular releases on a
reasonably predictable schedule. Even kernel releases, once known to slip
for a year or more, are now predictable to within a couple of weeks. Now
that free software releases are rather more predictable and reliable than,
say, airline departures, why is the Ubuntu 8.04 release noteworthy?
The answer is the long-term support commitment. Theoretically, a
distribution intended for this sort of long lifetime will have had a degree
of extra care put into its preparation. Important components will have
been given extra time to stabilize so that the distribution will be more
reliable from the outset. Some thought will have gone into the selection
of packages shipped with an emphasis on supportability over the long term.
The whole process requires more effort and a higher degree of assurance
that all of the pieces are truly ready.
The degree to which Ubuntu has done all of that work should become clear
over time. Certainly the software selected for this release is rather less
seasoned than the packages found in a Red Hat or SUSE enterprise release.
But "older" does not necessarily mean "better" or "more stable," so the
real proof will be in how well this distribution holds up for the next
Meanwhile, Mr. Shuttleworth has already stated that the next long-term
support release will be happening in April, 2010. Ubuntu's success with
8.04, he says, allows this commitment to be made almost two years in
advance. There is, however, a possibility that things could change:
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.
This idea is not new, but Mr. Shuttleworth seems to be particularly
attached to it. There is no doubt that there would be advantages to
aligning schedules in this way. The kernel developers, who have been known
to make a special effort for a release destined to be used by a major
enterprise distributor, could focus especially hard on a stable release
knowing that it would be widely used. Higher-level projects could do the
same. The distributors could also, perhaps, find a way to collaborate on
the long-term maintenance of these components, rather than duplicating the
effort of backporting patches into older code. Perhaps they could even get
together for a joint release party, saving even more money.
Or perhaps this is all a nice idea which fails to survive its encounter
with reality. Enterprise distribution releases tend to be
highly-publicized events. Ubuntu might be happy to share its limelight
with the larger distributors, but that feeling might not be reciprocated on
the other side. It is hard to imagine Red Hat or Novell wanting to have
their big enterprise distribution release be just one of many happening
during the same month.
It is also hard to see Ubuntu making an agreement with the
enterprise distributors which specifies both a release date
and the versions of the major components. 8.04 released with the 2.6.24
kernel, which was almost exactly three months old at the time. Red Hat
Enterprise Linux 5 released in mid-March, 2007, when the 2.6.20 kernel
was current - but Red Hat shipped the six-month-old 2.6.18 kernel instead.
Aligning schedules would require more than picking a date; it would also
require adopting similar stabilization periods. It is far from clear that
Ubuntu would want to fall that far behind the leading edge for the sake of
And, frankly, it's hard to imagine Debian making a credible commitment
(within one month) to a release date at all.
So the aligned schedules for enterprise distributions seems like a hard
sell. A better approach might be to try to wean these distributions off
the "freeze and backport" model of support; this model is expensive to
sustain, brings risks of its
own, and doesn't always fit
the needs of enterprise customers.. If the enterprise distributors
were able to track more current software - rather than backporting pieces
of it into older software - better alignment of releases might just come
to post comments)