|Deletions are marked like this.||Additions are marked like this.|
|Line 16:||Line 16:|
|* Reviewed and approved by a member of the curtin development team||* Reviewed and approved by a member of the development team|
DRAFT DRAFT DRAFT
This document describes the policy for updating Curtin in a stable supported distro, including LTS.
Curtin (the curt installer) is a "fast path" installer designed to install Ubuntu quickly. It is blunt, brief, snappish, snippety and unceremonious. Periodically Curtin needs to be updated in order to take advantage of new features and bug fixes. Therefore, in addition to bug fixes, new features are allowed in an update as long as the conditions outlined below are met.
This is the mandatory QA process that the proposed packages have to pass. The following requirements must be met:
- Every change needs to be covered by a Launchpad bug to track all changes
- Every bug must have:
- A bzr branch attached with the fix + changes covered by unit tests
- Link to successful run of integration tests based on the bzr branch
- Reviewed and approved by a member of the development team
- Branch set to the committed state
- All unit tests and style tests ran and passed successfully
- Code coverage of changes or code coverage % either no change or increased(?)
Requesting the SRU
The SRU should be requested per the StableReleaseUpdates documented process.
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 change log, but in that case each of those bugs will need to be independently verified and commented on for the SRU to be considered complete.
The description of the bug should contain links to automatic testing results (e.g. Jenkins test runs) so that anyone can verify the testing that occurred and the results. Additionally, the SRU bug should be verbose in documenting any manual testing that occurs. See LP# 1588052 as an example