UbuntuImageUpdates
|
Size: 3568
Comment: Added the Snapd SRU process
|
← Revision 22 as of 2017-03-23 16:09:33 ⇥
Size: 4071
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| This document describes the policy for updating the snapd package in a stable supported distro, including LTS. | ## page was copied from SnapdUpdates This document describes the policy for updating the ubuntu-image package in a stable release. |
| Line 3: | Line 4: |
| snapd is the tool to interact with Ubuntu Core Snappy. This package is also used in the generation of the OS snap package and snappy Ubuntu Core images. One of the goals of this project is to keep your system always up-to-date with the latest security fixes and with the newest developed features. It was designed in a way that makes it easily extendable, so every new release provides bug fixes and shiny new features with a low risk of regressions. The team is working really fast with a continuos delivery process which results in a new version ready to be released every week. Therefore, in addition to critical bug fixes, new features and small improvements are allowed in an update '''as long as the conditions outlined below are met'''. | 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 [[SnapdUpdates|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. |
| Line 7: | Line 10: |
| This is the mandatory QA process that the proposed packages have to pass. The following requirements must be met: | Every change to ubuntu-image is proposed through the [[https://github.com/CanonicalLtd/ubuntu-image|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 [[http://autopkgtest.ubuntu.com/packages/ubuntu-image|autopackage tests]] on all supported Ubuntu releases. Branches are never merged if any test fails. This includes 100% unit test coverage. |
| Line 9: | Line 12: |
| * each change must be reviewed and approved by at least two ubuntu-core developers before being landed into the master branch. * each change must be fully tested at the unit level. * all the unit tests must pass in all the supported architectures. They are executed for one arch before the change is merged into master, and for all the architectures during the build of the deb package that will go into proposed. * each bug fix that affects the user interface must have one QA review. The QA engineer will verify that the bug is fixed in a system with the proposed package installed by executing an automated or manual test. * all the bugs reported in launchpad that will be fixed in this release must have a link to the pull request that fixes them. These bugs must be marked as "Committed" once that pull request is merged into master. * all the new user-facing features will be tested in a real system. * most of these tests are automated and executed as part of the autopkgtest suite of the deb and it's reverse-dependencies in a classic ubuntu system, and as part of the automated user-acceptance suite in a snappy Ubuntu system. * the tests that can't be automated are documented and manually executed when there are changes in the code that can affect the feature. * when a new version is ready to be proposed, the QA team will perform extensive exploratory testing on the areas that will be changed by the release. |
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. With ubuntu-image 1.0, we also have autopkgtests that use ubuntu-image to build and boot an amd64 image. If the image doesn't boot, verified by connecting to an echo server in the running image, then the new version fails QA. While the boot test only tests amd64, it does test this in all release channels. Boot test: {{{ $ ubuntu-image model/pc-amd64-model.assertion -o /tmp/yakkety.img $ qemu-system-x86_64 -m 2G /tmp/yakkety.img }}} (Season to taste for Xenial image building test. Also, you may have to twiddle with permissions if you testing this in a chroot.) All bugs fixed or features added are [[https://bugs.launchpad.net/ubuntu-image|tracked in Launchpad]] and clearly described in the {{{debian/changelog}}}. |
| Line 20: | Line 26: |
| The resulting package, with all the changes in place, must undergo and pass the following additional QA procedures: | |
| Line 22: | Line 27: |
| * upgrade test from previous version of the package. This test must be performed with: * using apt install/upgrade. * test interaction with classic apt install and update of debs to make sure that snapd doesn't interfere with the classic system: * reboot. * install and update a deb with apt. * test interaction with gnome software center: * install and update a snap. * install and update a deb. The above tests can be performed by any QA engineer. This is a package new in Ubuntu 16.04 LTS. Once we have another stable Ubuntu version released this should be added to the above process: * upgrade test from previous distribution to the current one. If the current distribution is an LTS one, the upgrade path from the previous LTS distro must also be exercised. |
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. |
| Line 38: | Line 30: |
| The SRU should be requested as usual ([[StableReleaseUpdates]]) with the additional note about having the above steps being completed. | 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 Bug: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. |
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. With ubuntu-image 1.0, we also have autopkgtests that use ubuntu-image to build and boot an amd64 image. If the image doesn't boot, verified by connecting to an echo server in the running image, then the new version fails QA. While the boot test only tests amd64, it does test this in all release channels.
Boot test:
$ ubuntu-image model/pc-amd64-model.assertion -o /tmp/yakkety.img $ qemu-system-x86_64 -m 2G /tmp/yakkety.img
(Season to taste for Xenial image building test. Also, you may have to twiddle with permissions if you testing this in a chroot.)
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)