OpenStackSRUs

Revision 18 as of 2016-05-05 20:17:26

Clear message

Overview

This page documents the Stable Release Update process for the Ubuntu Cloud Archive.

Stable Release Updates

The SRU process for the Ubuntu Cloud Archive is aligned with the Ubuntu Stable Release Update process and follows the same process.

The following reiterates some key points from the Ubuntu SRU process:

  • Users of official releases expect a high degree of stability.
  • It is critically important to treat SRUs with great caution.
  • SRUs must be accompanied by a strong rationale and present a low risk of regression.
  • Minimizing risk tends to be well-correlated with minimizing the size of the change. As such, the same bug may need to be fixed in different ways in stable and development releases.
  • Stable release updates will, in general, only be issued in order to fix:

    • New upstream microreleases (e.g. OpenStack stable point releases that group several bug fixes)

    • High-impact bugs (e.g. security vulnerabilities, severe regressions, loss of user data)
    • Bugs that are not high-impact, but have an obviously safe patch
  • SRUs must have an accompanying bug with well-documented information for [Impact], [Test Case], and [Regression Potential].
  • Bugs must first be fixed in the latest upstream release where the bug exists before being backported to the accompanying UCA. The same bug may then be fixed in the prior upstream release before being backported to the accompanying UCA.

    • For example, the current development release of OpenStack is Newton which contains a bug. The bug must be fixed in Newton upstream first, and can then be backported to the UCA for Newton. The bug can then be fixed in the Mitaka upstream stable branch, and can then be backported to the UCA for Mitaka.

    • Landing a fix upstream may not be possible one the upstream branch is in security-fix only mode or once it is EOL. See the OpenStack upstream stable branch policy, which specifies:

      • Phase I (first 6 months): All bugfixes (which meet the criteria described below) are appropriate
      • Phase II (6-12 months): Only critical bugfixes and security patches are acceptable
      • Phase III (more than 12 months): Only security patches are acceptable (typically supported to a max of 18 months)

Getting Package Source

Depending on the package and the release, there are different ways to download the package source:

  • Core OpenStack package for Liberty+ can be found here. The process for working with these repositories can be found here.

  • Core OpenStack packages prior to Liberty are maintained in Bazaar.

  • UCA packages that correspond to a supported Ubuntu release:

    • pull-lp-source <package> [release|version] (e.g. pull-lp-source python-oslo.messaging xenial)

  • UCA packages that correspond to an unsupported Ubuntu release:

    • If the corresponding Ubuntu release has reached end of life, then the package source can be retrieved directly from the UCA staging PPA. For example, see the Mitaka staging PPA.

Providing A Fix

Fixes can be provided as:

  • A debdiff attached to the SRU bug
  • Package source pushed to a git repo (or bzr branch).