Methods and processes for releasing updated Ubuntu 6.06 CD images to correct (at least) installer bugs.


At the time of writing a week after the release of Ubuntu 6.06 LTS, several installer issues have already arisen which are known to affect many users and which generate enormous numbers of bug reports. (This is not too surprising since we released a completely new installer frontend.) Part of long-term support for this release should include a means to correct installer bugs, which involves re-rolling CD images.

Most developer resources will be concentrated on Edgy (and so on); we do not wish to divert significantly more resources into preparing point releases than have already been dedicated to preparing updated packages. A point release process should be as lightweight as possible while still maintaining a reasonable level of QA.

Shipit considerations

It has not yet been settled whether Shipit will continue operations for Dapper after Edgy is released. However, we would like to have at least one Shipit batch including an updated installer etc., so we will try to produce the first point release some time before Edgy releases to be on the safe side.

The point release managers must coordinate with HandeBayraktar to ensure that a batch of CDs is not produced immediately before a point release.

Support considerations

Point release managers need to be careful to avoid invalidating certifications on point releases. LSB certifications seem likely to remain valid (confirmed on IRC by JeffLicquia) for the lifetime of dapper. Other vendor certifications may well depend on interfaces not changing too radically (which is sensible for dapper-updates anyway).

Vendors who provide kernel modules will have to rebuild those for the point releases if the kernel module ABI changes; given that at the time of writing there has already been a dapper security update that changed the kernel module ABI, this seems unavoidable.

The support team would like to have good traceability of the contents of Dapper at its original release and at each point release.

The support team and curious end users would both like to be able to identify a point-release system (whether from a fresh install or upgraded) by means of lsb_release, /etc/issue, etc.

Distro considerations

Colin thinks suitable Ubiquity updates can be ready by mid-July.

Ben says the last expected Dapper kernel upload for a while is coming very soon (always barring security updates).

GNOME 2.14.3 is tentatively scheduled for 2 August; get JeffWaugh to make sure this happens (slightly earlier would be better to allow some burn-in time).

Use cases


As problems arise and are triaged in Dapper, developers will upload to dapper-security and dapper-updates in the normal course of events. We will ensure that dapper-proposed is operational so that complicated uploads can be staged there if required.

Each point release will proceed as follows:

Outstanding issues

Stage in dapper versus dapper+1: the former involves making a bunch of stuff visible to users as dapper before the point release has been finalised, and the latter involves more complexity in the dists/ tree.

Soyuz coordination required to make sure this all works; AdamConrad to liaise.

BoF notes


DapperPointReleaseProcess (last edited 2008-08-06 16:37:48 by localhost)