SRU

Differences between revisions 1 and 33 (spanning 32 versions)
⇤ ← Revision 1 as of 2006-10-31 01:01:29 →
Size: 6283
Editor: smtp
Comment:
← Revision 33 as of 2007-03-07 17:29:05 → ⇥
Size: 4936
Editor: i59F726DE
Comment:
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
= '''Proposed''' Universe SRU Policy = = Universe SRU Policy =
Line 7: Line 7:
In contrast to pre-release versions, official releases of Ubuntu are subject to much wider use, and by a different demographic of user. During development, \
changes to the distribution primarily affect developers, early adopters and other advanced users, all of whom have elected to use pre-release software at the\
ir own risk.		 In contrast to pre-release versions, official releases of Ubuntu are subject to much wider use, and by a different demographic of user. During development, changes to the distribution primarily affect developers, early adopters and other advanced users, all of whom have elected to use pre-release software at their own risk.
Line 11: Line 9:
Users of the official release, in contrast, expect a high degree of stability. They use their Ubuntu system for their day-to-day work, and problems they exp\
erience with it can be extremely disruptive. Many of them are less experienced with Ubuntu and with Linux, and expect a reliable system which does not requi\
re their intervention.		 Users of the official release, in contrast, expect a high degree of stability. They use their Ubuntu system for their day-to-day work, and problems they experience with it can be extremely disruptive. Many of them are less experienced with Ubuntu and with Linux, and expect a reliable system which does not require their intervention.
Line 15: Line 11:
Stable release updates are automatically recommended to a very large number of users, and so it is critically important to treat them with great caution. Th\
erefore, when updates are proposed, they must be accompanied by a strong rationale and present a low risk of regressions.		 Stable release updates are automatically recommended to a very large number of users, and so it is critically important to treat them with great caution. Therefore, when updates are proposed, they must be accompanied by a strong rationale and present a low risk of regressions.
Line 18: Line 13:
For packages in the Universe & Multiverse component, whilst they are popular, they are not installed by default & therefor have a lower risk of affecting man\
y users if a regression occurs

== When ==

Stable release updates will, in general, only be issued in order to fix '''high-impact bugs'''. Examples of such bugs include:

 * Bugs which may, under realistic circumstances, directly cause a '''security vulnerability'''
 * Bugs which represent '''severe regressions''' from the previous release of Ubuntu
 * Bugs which may, under realistic circumstances, directly cause a '''loss of user data'''		 For packages in the Universe and Multiverse components, whilst they are popular, they are not installed by default and therefore have a lower risk of affecting many users if a regression occurs.
Line 39: Line 25:
This process is to be followed for all updates '''except''' those to fix security updates, which are only released by the Ubuntu security team. Security pro\
cedures are documented at SecurityUpdateProcedures.		 This process is to be followed for all updates '''except''' those to fix security updates, which are only released by the Ubuntu security team. Security procedures are documented at SecurityUpdateProcedures.
Line 42: Line 27:
 1. Propose
Line 44: Line 28:
  All proposals for stable release updates must be '''approved''' by members of the [https://launchpad.net/people/motu-sru MOTU Stable Release Updates team].\
  SRU proposals must be accompanied by the following information for each bug to be addressed:		  1. Prepare
Line 47: Line 30:
   * A '''bug number''' referring to a complete bug report describing the problem and its effect
   * A '''statement explaining the impact''' of the bug on users and justification for backporting the fix to the stable release
   * An explanation of '''how the bug has been addressed''' in the development branch, including the relevant version numbers of packages modified in order t\
o implement the fix
   * A '''patch''' applicable to the stable version of the package. If preparing a patch is likely to be time-consuming, it may be preferable to discuss the\
 first three items before preparing a patch.

  A copy of this proposal and a hyperlink to any prior discussion thread should be added to the bug report as a comment, usually by CCing ''bugnumber''`@bugs\
.launchpad.net`.

1. Prepare

  Once an update has been discussed and approved in principle, an upload can be prepared. The following criteria apply to any packages modified as part of t\
he update:		   Once an update has been agreed on and falls under the criteria above, an upload can be prepared. The following criteria apply to any packages modified as part of the update:
Line 63: Line 33:
   * The bug report must include an '''approved SRU proposal'''
 * The '''version number(s)''' must be carefully checked in order to avoid clashing with any other version of the package, past, present or future		    * The '''version number(s)''' must be carefully checked in order to avoid clashing with any other version of the package, past, present or future. A general "best practice" is to use the suffix {{{~proposed1}}} or {{{~prop1}}}.
Line 67: Line 36:
  Uploads which do not meet these criteria will be '''rejected''' by an archive administrator and not published. Once the upload is ready, attach a complete\
 source package diff (`debdiff`) to the bug report for review.		   Once the upload is ready, attach a complete source package diff (`debdiff`) to the bug report for review.     The sponsor of the upload is responsible for testing the update.
Line 72: Line 43:
  The upload will be reviewed by the archive administrators, and approved if it meets the above criteria. Archive administrators should verify that the pack\
age delta matches the debdiff attached to the bug report.		   After the upload, archive administrators should then verify that the version number of the upload is sane and accept the package into -proposed. They set the bug status to `Fix committed`.
Line 78: Line 48:
  * Notify the MOTU team via the ubuntu-motu mailing list [mailto:ubuntu-motu@lists.ubuntu.com <ubuntu-motu@lists.ubuntu.com>] of the availability of this pa\
ckage for testing		   * Notify the MOTU team via the ubuntu-motu mailing list [mailto:ubuntu-motu@lists.ubuntu.com <ubuntu-motu@lists.ubuntu.com>] of the availability of this package for testing
Line 81: Line 50:
   * Add a `verification-needed` tag to the bug report.    * Add a `verification-motu-needed` tag to the bug report.
Line 83: Line 52:
  * If the testing period is over and there 2 persons have stated "works for me", motu-sru will set the tag `verification-motu-done`.
Line 85: Line 55:

  After successful testing and a minimum aging period of '''7 days''', you may prepare a second upload to ''release''`-updates`:		   
  After at least '''2 persons''' have tested the package and attached a "works for me" comment to the bug and after a minimum aging period of '''7 days''', motu-sru will prepare a second upload to ''release''`-updates`:
  
Line 93: Line 63:
  The archive administrators must verify that uploads to `-updates` meet these criteria. In the future, the update from `-proposed` will be copied verbatim \
instead, once the necessary infrastructure is available.		   The archive administrators must verify that uploads to `-updates` meet these criteria. In the future, the update from `-proposed` will be copied verbatim instead, once the necessary infrastructure is available.
Line 100: Line 69:
  * In the event of a regression, '''immediately''' notify the [mailto:ubuntu-motu@lists.ubuntu.com Ubuntu Universe maintainers] via email, and ask for help \
on `#ubuntu-motu` in making contact with a member of the MOTU SRU team.		   * In the event of a regression, '''immediately''' notify the [mailto:ubuntu-motu@lists.ubuntu.com Ubuntu Universe maintainers] via email, and ask for help on `#ubuntu-motu`.
Line 105: Line 73:
As reference you can lookup [https://launchpad.net/distros/ubuntu/+source/cpio/+bug/59228] to have an idea on how the procedure works. ''Old procedure'': As reference you can lookup [https://launchpad.net/ubuntu/+source/cinepaint/+bug/65457] to have an idea on how the procedure works.


----
["CategoryMOTU"]

Universe SRU Policy

Once an Ubuntu release has been completed and published, updates for it are only released under certain circumstances, and must follow a special procedure.

Why

In contrast to pre-release versions, official releases of Ubuntu are subject to much wider use, and by a different demographic of user. During development, changes to the distribution primarily affect developers, early adopters and other advanced users, all of whom have elected to use pre-release software at their own risk.

Users of the official release, in contrast, expect a high degree of stability. They use their Ubuntu system for their day-to-day work, and problems they experience with it can be extremely disruptive. Many of them are less experienced with Ubuntu and with Linux, and expect a reliable system which does not require their intervention.

Stable release updates are automatically recommended to a very large number of users, and so it is critically important to treat them with great caution. Therefore, when updates are proposed, they must be accompanied by a strong rationale and present a low risk of regressions.

For packages in the Universe and Multiverse components, whilst they are popular, they are not installed by default and therefore have a lower risk of affecting many users if a regression occurs.

When

Stable release updates will, in general, only be issued in order to fix high-impact bugs. Examples of such bugs include:

  • Bugs which may, under realistic circumstances, directly cause a security vulnerability

  • Bugs which represent severe regressions from the previous release of Ubuntu

  • Bugs which may, under realistic circumstances, directly cause a loss of user data

How

This process is to be followed for all updates except those to fix security updates, which are only released by the Ubuntu security team. Security procedures are documented at SecurityUpdateProcedures.

  1. Prepare
    • Once an update has been agreed on and falls under the criteria above, an upload can be prepared. The following criteria apply to any packages modified as part of the update:

      • The changelog entry and resulting .changes file must include a reference to the corresponding bug report(s)

      • The version number(s) must be carefully checked in order to avoid clashing with any other version of the package, past, present or future. A general "best practice" is to use the suffix ~proposed1 or ~prop1.

      • The upload target must be release-proposed

      Once the upload is ready, attach a complete source package diff (debdiff) to the bug report for review. The sponsor of the upload is responsible for testing the update.

  2. Upload

    • After the upload, archive administrators should then verify that the version number of the upload is sane and accept the package into -proposed. They set the bug status to Fix committed.

  3. Test

    • Once the update has been published in -proposed, it can be tested by a wider audience.

    • Notify the MOTU team via the ubuntu-motu mailing list [mailto:ubuntu-motu@lists.ubuntu.com <ubuntu-motu@lists.ubuntu.com>] of the availability of this package for testing

      • Prepend "StableReleaseUpdates" to the Subject line of your e-mail.

      • Add a verification-motu-needed tag to the bug report.

    • Test the package yourself

    • If the testing period is over and there 2 persons have stated "works for me", motu-sru will set the tag verification-motu-done.

  4. Release

    • After at least 2 persons have tested the package and attached a "works for me" comment to the bug and after a minimum aging period of 7 days, motu-sru will prepare a second upload to release-updates:

    • Include a changelog entry with:
      • A new version number (the same cautions apply regarding the choice of version number)

      • Confirmation of the above testing, including the name of the tester in each case

    • Make no other changes relative to the version in -proposed

      The archive administrators must verify that uploads to -updates meet these criteria. In the future, the update from -proposed will be copied verbatim instead, once the necessary infrastructure is available.

  5. Following up

    • Add yourself as a bug contact for the package in Launchpad, if you are not one already

    • For 7 days after the update is released, monitor Launchpad for bug reports relating to the update

    • In the event of a regression, immediately notify the [mailto:ubuntu-motu@lists.ubuntu.com Ubuntu Universe maintainers] via email, and ask for help on #ubuntu-motu.

Examples

Old procedure: As reference you can lookup [https://launchpad.net/ubuntu/+source/cinepaint/+bug/65457] to have an idea on how the procedure works.

["CategoryMOTU"]

MOTU/SRU (last edited 2008-08-06 16:22:55 by localhost)