DapperPointReleaseProcess

Differences between revisions 6 and 7
Revision 6 as of 2006-06-20 15:29:50
Size: 5565
Editor: ALagny-109-1-9-37
Comment: shipit
Revision 7 as of 2006-06-20 15:36:31
Size: 6459
Editor: ALagny-109-1-9-37
Comment: support considerations
Deletions are marked like this. Additions are marked like this.
Line 44: Line 44:
=== 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.
Line 60: Line 70:
 * careful of certifications
Line 72: Line 80:
 * change descriptive text in lsb-release (JeffBailey to check LSB policy on this), motd, issue, issue.net, CD image labels, etc.  * change descriptive text in lsb-release, motd, issue, issue.net, CD image labels, etc.

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.

At some point, Canonical's "Shipit" facility for Ubuntu 6.06 will be superseded by later releases. However, it may be useful to update the images pressed by Shipit at some point before that date.

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

Shipit considerations

It has not yet been settled whether Shipit will continue operations for Dapper after Edgy is released. However, since we would like to have at least one Shipit batch including an updated installer etc., 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.

Outstanding issues

BoF agenda and discussion

ColinWatson sees two reasonable approaches to package selection:

  • Prepare images based on the current state of dapper + dapper-updates + dapper-security. This avoids having to think about things too much, guarantees we don't miss anything, and is easy to implement, but requires a longer test cycle and means that we have to be even more careful about dapper-updates uploads.
  • Prepare images based on dapper plus manually-selected fixes. This means that we can concentrate on testing the relatively few things that have changed and means that dapper-updates acceptance policy can be not quite so conservative, but it requires somebody to keep track of all the required fixes and may require manual tweaking when building the live filesystems and CD images.

Roughly when should we schedule the first point release?

Should we attempt to move dapper-updates/dapper-security uploads into dapper when a point release happens? (This is not necessary in order to produce updated images, but it may or may not be desirable for other reasons.)

Notes

  • require multiple dapper suites, dapper.1, dapper.2, etc., for tracking, support certification, keeping everything in pool (preserve dapper.0 suite); AdamConrad will coordinate with Soyuz

  • need dapper-proposed operational in order to stage large uploads to dapper-updates

  • publish update CDs as well
  • schedule: beginning of August? GNOME 2.14.3 tentatively 2 August; get JeffWaugh to make sure this happens (slightly earlier would be better to allow a bit of burn-in)

  • Ben says last dapper kernel upload for a while coming RSN
  • change descriptive text in lsb-release, motd, issue, issue.net, CD image labels, etc.


CategorySpec

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