MicroReleaseExceptions

Differences between revisions 20 and 21
⇤ ← Revision 20 as of 2012-05-15 04:05:19 →
Size: 2527
Editor: pitti
Comment: TB approved postfix MRE
← Revision 21 as of 2012-06-19 14:10:47 → ⇥
Size: 2568
Editor: pitti
Comment: TB via pitti approved ubuntuone
Deletions are marked like this. Additions are marked like this.
Line 23: Line 23:
  * Ubuntu One (approved on 2012-06-19)

This was ratified by the Tech Board on 2007-08-14.

SRU micro version update exception

  • Allow for an exception in SRUs to the "patch must be as small and unintrusive as possible" requirement for specific packages that meet the criteria:

    • upstream supports micro-version updates to stable releases
    • upstream has a sufficiently high level of regression testing for their stable releases
    • regression tests are enabled in the package's build

  • The technical board will have the responsibility to maintain and review the list of packages that are exceptions to the SRU rule, as well as approve package additions.

    • Changes to the exception list must be brought to the TB via email (technical-board@lists.ubuntu.com). The request is expected to include justification against the above criteria.

    • Changes can be approved via any single TB member
  • Approved exceptions:
    • firefox
    • mozilla-thunderbird, thunderbird
    • seamonkey (approved on 2011-01-25)
    • postgresql-X.Y
    • clamav (approved on 2009-01-09)

    • bzr (approved on 2010-09-21); conditions: test suite running during package build from Ubuntu 11.04 on; SRU verification should run test suite in installed sytem

    • chromium-browser, chromium-codecs-ffmpeg, gyp (approved on 2010-11-02)

    • KDE (approved on 2010-11-16)

    • Banshee (approved on 2011-06-30)

    • postfix (approved on 2012-05-14)
    • Ubuntu One (approved on 2012-06-19)

  • SRU verification for Micro Release Exceptions:

    • For MRE packages only, it can generally be assumed that bugs claimed to be fixed have actually been fixed upstream, and it is not necessarily to manually independently verify them. (Some bugs may deserve specific verification if for example they are hard to reproduce upstream.)
    • Testing should generally concentrate on broad smoke tests to make sure no new regressions have been introduced.
    • The upstream test suite should be run from the built packages.
    • The diff should be reviewed to ensure no accidental or inappropriate changes were introduced during the micro-release.

    • When the preceding steps have been done, the headline bug (only) should be marked verification-done

StableReleaseUpdates/MicroReleaseExceptions (last edited 2015-09-29 16:25:28 by pitti)