UbuntuImageUpdates

Differences between revisions 19 and 20
Revision 19 as of 2016-10-20 05:15:00
Size: 3674
Editor: vorlon
Comment:
Revision 20 as of 2016-10-20 18:40:04
Size: 3865
Editor: localhost
Comment:
Deletions are marked like this. Additions are marked like this.
Line 12: Line 12:
We do not currently test actual image building and booting in the CI infrastructure, but this is a [[https://bugs.launchpad.net/ubuntu-image/+bug/1625732|planned task in LP: #1625732]]. In the meantime, we will perform manual testing of image building of the [[http://people.canonical.com/~vorlon/official-models/|official models]]. Manual testing will also confirm that the resulting images can be mounted, and for hardware where it's possible, we can manually test booting. Over time, and as part of the LP: #1625732 work, we will move these manual tests into the automated test infrastructure. With [[https://bugs.launchpad.net/ubuntu-image/+bug/1635337|LP: #1635337]] (ubuntu-image 0.9), we build all of the [[http://people.canonical.com/~vorlon/official-models/|official models]] on every merge proposal, and verify that all mountable partitions can actually be mounted, including the unspecified ''writable'' partition at the end of the disk image, but not including any MBR "non-partitions" at the front. We do not currently test actual image booting in the CI infrastructure, but this is a [[https://bugs.launchpad.net/ubuntu-image/+bug/1625732|planned task in LP: #1625732]]. In the meantime, we will perform manual boot testing of images where possible. Over time, and as part of the LP: #1625732 work, we will move these manual tests into the automated test infrastructure.

This document describes the policy for updating the ubuntu-image package in a stable release.

ubuntu-image is a tool for building bootable images for a variety of devices and Ubuntu flavors. Initially, it is primarily used to build bootable snappy images, but will eventually expand its use cases to include Ubuntu classic. ubuntu-image is closely tied to snapd, since it depends on snapd for interaction with the snappy store, and for validating models and gadgets. Thus, the snapd updates policy has relevance. As new snapd releases are made, new ubuntu-image releases may also be necessary. Even without snapd releases, new ubuntu-image releases may be necessary in order to facilitate image building on the Ubuntu infrastructure, including potentially on LTS releases (although ubuntu-image only became available in the archive as of 16.10). Since at the time of 16.10 release, it is known that ubuntu-image is not feature complete, and its focus is narrowly defined to be for image building, new featureful releases will be made on the in-development version of Ubuntu, in stable releases, and in the snap store. It is a project goal to keep all release channels in sync.

The QA process for stable ubuntu-image releases are outlined below, in support of an exception to the standard SRU process.

QA Process

Every change to ubuntu-image is proposed through the GitHub merge proposal process. It is generally reviewed by at least one other member of the ubuntu-image team, although because of the team's size this cannot always be guaranteed. Continuous integration is performed on all pull requests, using DEP-8 style autopackage tests on all supported Ubuntu releases. Branches are never merged if any test fails. This includes 100% unit test coverage.

With LP: #1635337 (ubuntu-image 0.9), we build all of the official models on every merge proposal, and verify that all mountable partitions can actually be mounted, including the unspecified writable partition at the end of the disk image, but not including any MBR "non-partitions" at the front. We do not currently test actual image booting in the CI infrastructure, but this is a planned task in LP: #1625732. In the meantime, we will perform manual boot testing of images where possible. Over time, and as part of the LP: #1625732 work, we will move these manual tests into the automated test infrastructure.

All bugs fixed or features added are tracked in Launchpad and clearly described in the debian/changelog.

Packaging QA

Candidate packages are tested in all release channels through an install/upgrade process, by installing the existing archive version and upgrading to the latest built package.

Requesting the SRU

The SRU should be requested as usual (StableReleaseUpdates) with the description of the bug containing links to automatic testing results (github autopkgtest results) so that any one can verify the testing occurred and its results. Additionally, the SRU bug should be verbose in documenting any manual testing that occurs. (An example of a good SRU bug can be found in 1588052.) The SRU should be done with a single process bug for this stable release exception, instead of individual bug reports for individual bug fixes. Individual bugs may be referenced in the changelog, but in that case each of those bugs will need to be independently verified and commented on for the SRU to be considered complete.

UbuntuImageUpdates (last edited 2017-03-23 16:09:33 by localhost)