CurtinUpdates

Differences between revisions 3 and 4
Revision 3 as of 2017-01-27 20:40:57
Size: 2041
Editor: powersj
Comment:
Revision 4 as of 2017-02-01 17:49:55
Size: 2034
Editor: powersj
Comment:
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.

QA Process

Merge QA

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(?)

Packaging QA

TBD

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

SRU Template

TBD

CurtinUpdates (last edited 2017-04-05 20:06:54 by vorlon)