DapperPointReleaseProcess

Differences between revisions 1 and 2
Revision 1 as of 2006-06-07 01:26:24
Size: 2330
Editor: 83-216-156-196
Comment: start, use cases
Revision 2 as of 2006-06-07 09:21:50
Size: 4122
Editor: 83-216-156-196
Comment: more rationale, another use case, BOF agena
Deletions are marked like this. Additions are marked like this.
Line 16: Line 16:
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.
Line 28: Line 32:
 * 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.
Line 29: Line 35:

== Implementation ==

=== Code ===

=== Data preservation and migration ===
Line 40: Line 40:
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.

When will Shipit cease operations for 6.06?

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.)

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.

Design

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.

When will Shipit cease operations for 6.06?

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.)


CategorySpec

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