FreezeExceptionProcess

Revision 34 as of 2008-03-28 04:34:23

Clear message

As with most rules, there are occasional exceptions to the restrictions imposed by the various stages of the Ubuntu release process. These exceptions are granted by the release team based on information provided by the developer who proposes the change.

TableOfContents()

General Instructions

Requests for freeze exceptions for main should be filed as bugs in launchpad against the relevant package (or just "Ubuntu" if the package is not available yet). Once the bug is filed and the necessary information is available, subscribe [https://launchpad.net/~ubuntu-release ubuntu-release] (main, restricted) or [https://launchpad.net/~motu-release motu-release] (universe, multiverse). All freeze exceptions must include the following information, in order to provide them with enough information to weigh the risk of regressions against the benefit of the changes:

  • A description of the proposed changes, with sufficient detail to estimate their potential impact on the distribution
  • A rationale for the exception, explaining the benefit of the change
  • Any additional information which would be helpful in considering the decision

FeatureFreeze Exceptions

A request for an exception to FeatureFreeze should demonstrate that the benefit of new functionality, or the total benefit of a new upstream release which includes it, outweighs the risk of regressions and other potential disruption of the release process.

Exception requests must include the following additional details:

  • diffstat output showing the magnitude of code changes relative to the current version in Ubuntu

  • If the upload is a new upstream microrelease, the relevant part of the upstream changelog and/or release notes
  • An explanation of the testing which has been performed on the new version in Ubuntu, including verification that the new package:
    • builds,
    • installs and upgrades,
    • does not break packages which depend on it, or that corresponding updates have been prepared.

UserInterfaceFreeze Exceptions

The exception request bug report needs to have a justification why the user interface needs to be changed at that point, and give a rationale why the benefits of it are worth breaking existing documenation and translations.

Every change of the user interface (either a string or the layout) requires you to notify the [https://lists.ubuntu.com/mailman/listinfo/ubuntu-doc documentation] and [https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators translation] teams. Please include a link to these posts in the mailing list archives of [https://lists.ubuntu.com/archives/ubuntu-doc/ ubuntu-doc@] and [https://lists.ubuntu.com/archives/ubuntu-translators/ ubuntu-translators@].

After that, subscribe the release team, as usual.

Milestone freeze Exceptions (like BetaFreeze)

During milestone/final release freeze periods, extreme caution is exercised when considering exceptions, as a regression could cause a deadline to be missed, or a build to receive less testing than desired. A request for an exception must demonstrate strong rationale and minimal risk for the update to be considered.

Exception requests must include the following additional details:

  • It must fix a bug milestoned for that particular milestone.
  • A complete debdiff of the proposed upload must be provided (preferably as bug attachment).

Exceptions for Universe/Multiverse

FeatureFreeze for new upstream versions

If you want to introduce a new upstream version with new features and/or ABI/API changes, please

  • [https://launchpad.net/ubuntu/+filebug file a bug]

  • state the reason why you feel it is necessary

    • (other bugs it fixes, etc.)
  • attach (as files)
    • diffstat (recursively) of the directories resulting from untarring the upstream tarballs

      diff -ruN <package>-{old-version,new-version}/ | diffstat > diffstat.txt
    • diff of the Upstream ChangeLog (not debian/changelog)

      diff -u <package>-{old-version,new-version}/ChangeLog > changelog.diff
    • note that the ChangeLog sometimes is called CHANGES, is missing or the tarball merely has a NEWS file.

    • the NEWS file, if you think that this information helps reviewing your request (true for most gnome packages)

    • build log (as file)
      • pbuilder has the --logfile option.

    • install log
      • for instance a copy and paste of the install messages from console when installing
    • mention what testing you've done to see that it works
      • a screenshot showing the main features could also be nice
  • subscribe (not assign) it to the 'motu-release' team.

  • In some cases a standing freeze exception for multiple uploads is the most efficient way to manage the freeze process. Standing freeze exceptions should be requested in bugs using the normal process, although not all elements of a standard FFe request will apply. Once a standing FFe is approved (2 motu-release acks), it must be documented on the [wiki:StandingFeatureFreeze Standing Feature Freeze Exception] page.

Please note that we expect requesters to have an updated package already prepared and tested! You will need this anyway to provide proper diffstats and buildlogs.

Once one of the [https://launchpad.net/~motu-release team members] marks the bug as Confirmed you can either proceed with uploading (in case you're in [http://launchpad.net/~motu motu] or [http://launchpad.net/~ubuntu-core-dev ubuntu-core-dev]), else please follow ["SponsorshipProcess"].

References:

FeatureFreeze for bug fix only updates (process agreed by motu-release)

Up through RC, if a MOTU believes upload of a new upstream release that just has bug fixes in it is warranted, they may upload it using this process:

  • [https://launchpad.net/ubuntu/+filebug File a bug] in LP with the upstream change log entries in it (and rationale if it's not clear from that)

  • Mark it fix released when the upload is done to document that it was bug fix only
  • If you have doubts about if something qualifies, check with a member of motu-release (or subscribe motu-release to the bug) and if one person from motu-release agrees it's a bug fix update, you're good for upload.

FeatureFreeze for new packages

The motu-release team will consider exceptions, where additions of packages are worthwhile (up until BetaFreeze). Please note: the motu-release team will not review the package for you. You should have followed [:UbuntuDevelopment/NewPackages] before asking for an exception.

Process:

  • Follow [:UbuntuDevelopment#NewPackages].

  • File a bug, attach the source package to it (or link to it).
  • subscribe (not assign) the bug to motu-release.

  • State why the addition of the package should get considered.

Decision: ["MOTU/Council/Meetings/2007-02-23"].

Milestone Freeze

During the last week of development before the release, all uploads need to get approved by the release team. Usually they ask a MOTU team for approval of Universe and Multiverse packages.

Process:

  • Either file a bug with the debdiff and assign it to motu-release and get approval for it.

  • Or ask a member of the motu-release [http://launchpad.net/~motu-release team] on IRC of approval for the debdiff.

Decision: ["MOTU/Council/Meetings/2007-02-23"].


["CategoryProcess"]