Launchpad Entry: https://launchpad.net/distros/ubuntu/+spec/dapper-point-release-process
Created: 2006-06-07 by ColinWatson
Contributors: ColinWatson, AdamConrad, BenCollins, JeffBailey, JeffWaugh
Packages affected: N/A
Summary
Methods and processes for releasing updated Ubuntu 6.06 CD images to correct (at least) installer bugs.
Rationale
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
- Joe tries to install Ubuntu 6.06 LTS on an XFS root filesystem, only to find that Ubiquity crashes obscurely without either informing him of the problems with GRUB on XFS or falling back gracefully to LILO.
- Niamh tries to install Ubuntu 6.06 LTS, but forgets to format the target root filesystem. Ubiquity crashes obscurely rather than informing her of this problem.
- Ciaran plays with the Desktop CD a bit before starting the installation; among the things he does is to try to install some package which fails to configure properly. Undaunted, he starts the installation anyway. Unfortunately, the installer crashes while installing language packs.
- Bridget is installing Ubuntu 6.06 LTS on a old system at home two years after release, but doesn't want to have to spend hours downloading the security updates to the majority of installed packages that will probably have been released by that point. She would much rather have an updated CD image which she can download using the high bandwidth available to her at work.
- A security issue is discovered in the installer and needs to be corrected. (Typically this can and should be worked around in some more-or-less appropriate package's maintainer scripts, but updating the installer as well is preferable.)
- A security issue is discovered in a major network client application on the live CD, and is affecting many users. We wish to roll out a fix that doesn't require users to dedicate a large chunk of memory by upgrading the package on the fly.
- A server admin has a storage device that isn't quite supported by Dapper's kernel, but this bug can be corrected easily in an update. He wants to have an image from which he can install Dapper on this machine.
Design
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:
- Announce that preparation is underway (well in advance, so that developers have time to submit update proposals).
Rename the dapper distrorelease to the archival copy dapper.X (where X starts as 0), and ensure that the dapper symlink in the archive points to dapper.X. Create a new copy of dapper.X as dapper.X+1. Mark the old distrorelease as RELEASED (must not be touched) and the new one as FROZEN (no uploads, but may be changed with approval from distro managers).
Select candidate uploads from the list of updates in dapper-security and dapper-updates. (Make sure that debian-installer is updated if necessary.)
Update descriptive version strings in base-files and in the CD image build system.
Propagate these uploads (both source and binaries; the uploads must not be rebuilt!) into dapper.X+1 using a to-be-written tool. (No uploads directly to dapper will be accepted; everything must go through dapper-security or dapper-updates.)
Build live filesystems and CD images from dapper.X+1.
- Test CD images, paying particular attention to packages changed in this point release.
- Iterate upload propagation until satisfied.
Take an archival copy (not published anywhere) of dapper.X's images on releases.ubuntu.com.
Publish new CD images on releases.ubuntu.com.
- Wait long enough for all mirrors to pick up the new release.
- Announce.
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
- publish update CDs as well (will become a separate spec)