LTS Policies

Registered by Dustin Kirkland 

Ubuntu's LTS releases are a different breed from Ubuntu non-LTS releases. LTS releases occur every 2 - 2.5 years (every 4th or 5th Ubuntu release). LTS releases are supported by Canonical for 5 years. As such, businesses and enterprises tend to use LTS for stable, production systems, and more frequently, servers.

Since Ubuntu has produced 2 LTS releases so far (6.06 & 8.04), there are, perhaps, some lessons to be learned from the Dapper and Hardy development and support cycles, as well as, of course, the venerable Debian Stable releases.

Discussion Points:
 * What can we improve for the next LTS?
 * Would it make sense to sync some key packages from Debian stable instead of unstable?
 * Should we (and how can) we ensure that more time is spent during an LTS development cycle on bug fixing, rather than feature development? Earlier Feature Freeze and Debian Import Freeze dates?
 * How can we avoid/improve upon the Firefox3beta scenario in Hardy? What about really important, but beta-quality projects in Hardy, like kvm? Something like the Gnome 3.0 release will also present an interesting challenge. Should we handle this on a package-by-package basis, or establish a more comprehensive policy?

:-Dustin

Blueprint information

Status:
Complete
Approver:
Rick Clark
Priority:
Undefined
Drafter:
Dustin Kirkland 
Direction:
Needs approval
Assignee:
Steve Langasek
Definition:
Approved
Series goal:
None
Implementation:
Implemented
Milestone target:
milestone icon later
Started by
Dustin Kirkland 
Completed by
Dustin Kirkland 

Related branches

Sprints

Whiteboard

====================================
UDS Raw Notes (thanks to JonathanCarter)
====================================

Attendees to the session were mostly from the server team, so discussions were mostly server-centric. This specification applies to the whole Ubuntu LTS even though the discussions may seem to imply otherwise.

Dustin mentioned that it's a good time to start talking about the next LTS release, since the release is only a year away.

A planet Ubuntu user has expressed that they have switched to Debian because of some problems with Ubuntu LTS Server. Some people in the session have heard of similar situations. Mark expressed that there's nothing wrong with people using Debian if they like it more, but if there are reasons why people switch to Debian as apposed to Ubuntu LTS on a server then the reasons should be investigated and either solved or mitigated.

 * ACTION: Investigate why users would switch and what might have gone wrong

There's not really much difference between an LTS release and a normal release, sometimes there is more caution with packages going into an LTS release since maintainers realise that they have to maintain that package much longer.

Dustin suggested that it might be better syncing with Debian testing instead of Debian unstable for many packages in LTS, perhaps even as the default. There was a sendmail bug in dapper that swallowed 50000 emails and this bug didn't make it into Debian testing. Syncing to testing for server-side packages may result in better stability. It is possible syncing some parts of Ubuntu with testing, some with unstable and some from experimental. This may be another solution worth investigating. Maintaing some packages are problematic when they get old since upstream may have completely lost interest in that specific version. Being in sync with Debian testing may mitigate this problem since that version will be shared between Debian and Ubuntu. If the package sync would be changed, tracking how fast packages move fast would be useful, for example, we know that software such as php moves really fast where software such as postfix tents to be very stable and mature. 5 years down the line, any interpreted programming language such as php, python or ruby would be pretty much obsolete, users have to depend on backports for those.

 * ACTION: Investigate syncing policies with Debian development packages

People who tend to use software that is not in main often do not care about LTS releases. iscsi is still broken in hardy while samba and multipath had lots of issues, as a result some users upgrade to a non-LTS release. An LTS release should be at least as stable as Debian stable if not more so. Ubuntu shouldn't through away the reputation of Debian's solid server stability but should rather build on it. Mark explained that in the last 6 months, statistics shows us that enterprise adopters of OSS that deploy Ubuntu has grown from 18% to 27% (someone please check these stats, I'm not 100% sure that I took it down correctly --JonathanCarter), while all the other distributions shrank. The Ubuntu and Debian relationship is being worked on and being built on. Problems where things blow up after shipping should be focussed on.

 * ACTION: Investigate what has gone wrong in LTS-releases post-release, this can often be gauged by the changes between the initial release and the first point release

Changing the ratio between adding features and doing testing should perhaps be adjusted for LTS releases. Priorities should possibly change for LTS releases:

 * ACTION: Investigate what could be done to improve the quality of LTS releases specifically, and decide

The meme that there's a pulse with releases should be spread and instilled, for example, if kvm knows that a specific version of kvm goes into Ubuntu LTS and along-term version of OpenSuse for example, then they may put in more effort in testing for that upstream version and work harder on bug fixes than features.

 * ACTION: Identify problematic packages and get in touch with upstream maintainers

There wasn't much talk about kernels in this session, there was a previous session the morning already about backporting kernels and modules to LTS releases. Kernels from newer releases are being backported for hardy-backports as an experiment of what can go wrong when using newer kernels on older systems.

All of this should be discussed before the loopy development cycle begins.

(?)

Work Items