Differences between revisions 4 and 5
Revision 4 as of 2006-06-20 14:42:36
Size: 5036
Editor: ALagny-109-1-10-42
Comment: another use case
Revision 5 as of 2006-06-20 15:23:42
Size: 5258
Editor: ALagny-109-1-9-37
Comment: use case
Deletions are marked like this. Additions are marked like this.
Line 5: Line 5:
 * '''Contributors''': ColinWatson  * '''Contributors''': ColinWatson, AdamConrad, BenCollins, JeffBailey, JeffWaugh
Line 34: Line 34:
 * [TODO] updated hardware support, sometimes (e.g. storage device drivers)  * 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.
Line 67: Line 67:
 * coordinate with Hande on shipit


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.

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.


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?

  • Maybe three weeks before release, but not yet decided given LTS.

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


  • careful of certifications
  • 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? makes sure to catch shipit; 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)

  • coordinate with Hande on shipit
  • Ben says last dapper kernel upload for a while coming RSN
  • change descriptive text in lsb-release (JeffBailey to check LSB policy on this), motd, issue, issue.net, CD image labels, etc.


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