OpenStackSRUs

Differences between revisions 36 and 67 (spanning 31 versions)
⇤ ← Revision 36 as of 2016-05-05 21:41:17 →
Size: 4748
Editor: corey.bryant
Comment:
← Revision 67 as of 2016-05-10 11:44:58 → ⇥
Size: 4816
Editor: corey.bryant
Comment:
Deletions are marked like this. Additions are marked like this.
Line 2: Line 2:
=== Overview ===
Line 4: Line 3:
This page documents the Stable Release Update process for the Ubuntu Cloud Archive. === Stable Release Updates for OpenStack and the Ubuntu Cloud Archive ===
Line 6: Line 5:
=== Stable Release Updates === The SRU process for !OpenStack and the Ubuntu Cloud Archive follows the same process as [[https://wiki.ubuntu.com/StableReleaseUpdates|Ubuntu Stable Release Updates]]. Most of the points that are highlighted here are covered in further detail in the previous link, and are condensed and reiterated here with some additions that are specific to the Ubuntu Cloud Archive.
Line 8: Line 7:
The SRU process for the Ubuntu Cloud Archive follows the same process as the [[https://wiki.ubuntu.com/StableReleaseUpdates|Ubuntu Stable Release Update process]]. === SRU Expectations ===
Line 10: Line 9:
The following bullets highlight some key points that are mostly covered in detail in the Ubuntu SRU process (for more details see the link above):
Line 13: Line 11:
  * SRUs must be accompanied by a strong rationale and present a low risk of regression.   * SRUs must be accompanied by a strong rationale and must present a low risk of regression.
Line 16: Line 14:
    * New upstream stable point releases for !OpenStack core packages which 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 sections for [Impact], [Test Case], and [Regression Potential]. These sections must contain details as described in the [[https://wiki.ubuntu.com/StableReleaseUpdates|Ubuntu Stable Release Update process]].
  * Bugs must first be fixed in the latest upstream release [1] where the bug exists before being backported to the corresponding Ubuntu release [2], followed by backporting to the corresponding UCA. The same bug may then be fixed in the prior upstream release before being backported to the corresponding Ubuntu release and the accompanying UCA. And then it can be fixed in Liberty, Kilo, etc.		     * New upstream stable point releases for !OpenStack core packages which group several bug fixes together.
    * 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 sections for [Impact], [Test Case], and [Regression Potential]. These sections must contain details as described in the [[https://wiki.ubuntu.com/StableReleaseUpdates#Procedure|Ubuntu Stable Release Updates procedure]].
  * Bugs must be fixed in the following order, when possible:
    1. Upstream in the latest !OpenStack release [1]
    1. Then in the corresponding Ubuntu release [2]
    1. Then in the corresponding UCA release
    1. Then the bug can be fixed in the same order for the prior !OpenStack release (upstream stable first, corresponding Ubuntu release second, and corresponding UCA release third).
 [1] Landing a fix upstream may not always be possible, for example once the upstream branch is in critical-fix or security-fix only mode, or once it has reached EOL. See the [[http://docs.openstack.org/project-team-guide/stable-branches.html|OpenStack upstream stable branch policy]], which specifies the various phases of support for stable branches, which are typically supported for 12 to 18 months. The case where a bug can't be fixed upstream first must be handled with extreme caution, since fixes would be released directly to the corresponding Ubuntu release without having landed upstream first.
 
 [2] Landing a fix in a corresponding Ubuntu release may not always be possible, for example once the Ubuntu release has reached EOL and the UCA is still supported. This case must be handled with extreme caution, since fixes would be released directly to the corresponding UCA without having first landed in the corresponding Ubuntu release, and possibly also without having first landed in the upstream !OpenStack release.
Line 22: Line 27:
    * 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 corresponding Ubuntu release (Xenial), followed by backporting to the UCA for Newton. The bug can then be fixed in the Mitaka upstream stable branch, and can then be backported to the corresponding Ubuntu release (Wily), followed by backporting to the UCA for Mitaka.
    * [1] Landing a fix upstream may not be possible once the upstream branch is in critical-fix or security-fix only mode, or once it has reached EOL. See the [[http://docs.openstack.org/project-team-guide/stable-branches.html|OpenStack upstream stable branch policy]], which specifies the various phases of support for stable branches, which are typically supported for 12 to 18 months. This case must be handled with extreme caution, as fixes would be released directly to the corresponding Ubuntu release without having landed upstream first.
    * [2] Landing a fix in a corresponding Ubuntu release may not be possible once the Ubuntu release has reached EOL. This case must also be handled with extreme caution, as fixes would be released directly to the corresponding UCA without having first landed in the corresponding Ubuntu release, and possibly without having first landed in the upstream OpenStack release.		 === Nominating a Bug for a Series ===

A sponsor can be asked to nominate a bug for a particular series. You can find the following sponsors in #ubuntu-server on freenode:
 * To target an Ubuntu series: coreycb, jamespage
 * To target an Ubuntu Cloud Archive series: coreycb, jamespage, dosaboy, wolsen

Getting permission to target a bug for a series:
 * To gain permission to target a bug for an Ubuntu series you must be a member of: https://launchpad.net/~ubuntu-bugcontrol
 * To gain permission to target a bug for an Ubuntu Cloud Archive series you must be a member of: https://launchpad.net/~ubuntu-cloud-archive-bugs
Line 34: Line 45:
  * UCA packages that correspond to a supported Ubuntu release can be retrieved with the pull-lp-source tool.   * UCA packages that correspond to a supported Ubuntu release can be retrieved with the pull-lp-source tool:
Line 37: Line 48:
  * UCA packages that correspond to an unsupported Ubuntu release can be retrieved from the corresponding UCA staging PPA.
    * 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 [[https://launchpad.net/~ubuntu-cloud-archive/+archive/ubuntu/mitaka-staging/+packages|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).		   * UCA packages that correspond to an unsupported (EOL) Ubuntu release can be retrieved from the corresponding UCA staging PPA:
    * For example, see the [[https://launchpad.net/~ubuntu-cloud-archive/+archive/ubuntu/mitaka-staging/+packages|Mitaka staging PPA]].

Stable Release Updates for OpenStack and the Ubuntu Cloud Archive

The SRU process for OpenStack and the Ubuntu Cloud Archive follows the same process as Ubuntu Stable Release Updates. Most of the points that are highlighted here are covered in further detail in the previous link, and are condensed and reiterated here with some additions that are specific to the Ubuntu Cloud Archive.

SRU Expectations

  • 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 must 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 stable point releases for OpenStack core packages which group several bug fixes together.

    • 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 sections for [Impact], [Test Case], and [Regression Potential]. These sections must contain details as described in the Ubuntu Stable Release Updates procedure.

  • Bugs must be fixed in the following order, when possible:

    1. Upstream in the latest OpenStack release [1]

    2. Then in the corresponding Ubuntu release [2]
    3. Then in the corresponding UCA release

    4. Then the bug can be fixed in the same order for the prior OpenStack release (upstream stable first, corresponding Ubuntu release second, and corresponding UCA release third).

  • [1] Landing a fix upstream may not always be possible, for example once the upstream branch is in critical-fix or security-fix only mode, or once it has reached EOL. See the OpenStack upstream stable branch policy, which specifies the various phases of support for stable branches, which are typically supported for 12 to 18 months. The case where a bug can't be fixed upstream first must be handled with extreme caution, since fixes would be released directly to the corresponding Ubuntu release without having landed upstream first.

    [2] Landing a fix in a corresponding Ubuntu release may not always be possible, for example once the Ubuntu release has reached EOL and the UCA is still supported. This case must be handled with extreme caution, since fixes would be released directly to the corresponding UCA without having first landed in the corresponding Ubuntu release, and possibly also without having first landed in the upstream OpenStack release.

Nominating a Bug for a Series

A sponsor can be asked to nominate a bug for a particular series. You can find the following sponsors in #ubuntu-server on freenode:

  • To target an Ubuntu series: coreycb, jamespage
  • To target an Ubuntu Cloud Archive series: coreycb, jamespage, dosaboy, wolsen

Getting permission to target a bug for a series:

Getting Package Source

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

  • Core OpenStack packages for Liberty+ are maintained in git on Launchpad. The process for working with these repositories is documented here.

  • Core OpenStack packages prior to Liberty can be found maintained in Bazaar on Launchpad. The process for working with these branches is documented here.

  • UCA packages that correspond to a supported Ubuntu release can be retrieved with the pull-lp-source tool:

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

  • UCA packages that correspond to an unsupported (EOL) Ubuntu release can be retrieved from the corresponding UCA staging PPA:

ServerTeam/OpenStackSRUs (last edited 2016-06-07 19:49:15 by corey.bryant)