#title Targeting of Release-Critical Bugs

== Introduction ==

This page documents the intended use of milestones, release nominations, and bug importances to facilitate tracking bugs that are release-critical for a given Ubuntu release.  Consistent application of these guidelines is important to the success of Ubuntu releases, ensuring both that the time of the release team and QA team are used effectively and that bugs which should be release-critical are visible in appropriate lists where they will receive the necessary attention.

== Release nominations ==

To indicate that a bug should be fixed prior to the final release, please add the tag 'rls-q-incoming' if you want the bug to be considered by a development team for fixing.  Where 'q' denotes the appropriate release series for which it should be considered.  The tag should only be removed by someone empowered to decide for the team (manager/team lead/defect analyst) to accept the bug and targets it for that series explicitly.

Use of milestone targeting is not required except in cases where delivery of the bugfix is relevant to the success of the milestone release; release-criticality of bugs is instead identified by being accepted to a series for the release and being marked with an importance of "high" or above.

Release-critical bugs should all have designated assignees responsible for fixing the bug.  Bugs may be nominated as release-critical without an assignee, but the nomination should not be accepted without assigning the bug task to a person or team and the 'rls-q-incoming' tag removed.

Release-targeted bugs of "medium" importance or below will be considered targets of opportunity for a release rather than release-critical.  Nominating such bugs is useful for allowing the release team and other developers to know what these targets of opportunity are, and if appropriate, contribute to their completion.  Some of these bugs may not be resolved in time for a final release, and may not be suitable candidates for StableReleaseUpdates. It is recognized that this implies some post-release cleanup work to decline bugs previously accepted for the release so that the list of series-targeted bugs can be reused for SRUs.

In some cases a bug may be considered release critical for a release as a whole but be a low-impact issue for the package in question.  In cases where it is deemed inappropriate to raise the importance of a release-critical bug, the bug should instead be nominated for release and targeted to a specific milestone.  As a general rule, the milestone such bugs should be targeted to is the release candidate, since low-priority fixes will not be accepted by the release team between the RC and the final release.

== Milestones ==

For bugs that have been accepted as release-critical, use of Alpha, Beta, and RC milestones should be reserved for documenting those bugs which are blockers for the milestone release in question.

In the case of bugs that are not nominated for release, developers may use milestone targeting to indicate an intention to deliver the fix for the bug in time for that milestone.

Only those milestoned bugs which are also marked as release-critical, by way of targeting to the release, will be managed by the release team; developers who use milestones for tracking of non-release-critical bugs are individually responsible for following up on bugs which aren't resolved in time for the associated milestone release.

== Bugs that should be considered release-critical ==

In addition to bugs that have a high impact on the usability of the release, the following classes of bugs should be
treated as release-critical and targeted as such using the above methods:

 * Any changes that are made during the development cycle for pragmatic reasons which are intended to be reverted before the release.

== Untargeting bugs ==

If a bug is targeted for a release but developers feel it no longer should be, mark the task for the release as "Won't Fix". When you do this, a new task will appear on the package. This task will not have a targeted release set, but otherwise will have the same status as the task you just marked "Won't Fix".

If a bug is targeted for a release, but its clear the team responsible for that package won't have time to make the fix, please add the tag 'rls-q-notfixing' to the bug, so others may contribute.

== Release notes ==

In some cases, a bug cannot be fixed for the release and will merit a release notes entry instead. To note this, use "Also affects project" to add a task on the [[https://launchpad.net/ubuntu-release-notes|ubuntu-release-notes]] project. Please make sure to explicitly nominate against a series,  since release note can apply for multiple release.  Please make sure the bug has a clear description, and if possible provide some sample text for the release notes.   When the note has been added to the Release Notes, the status should be marked as "Fix Released"

----
CategoryProcess<<BR>>CategoryUbuntuDevelopment