RCBugTargetting
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.
Milestones
Alpha, Beta, and RC milestones for Ubuntu releases should be used exclusively for documenting those bugs which should be considered blockers for the milestone release in question. This means that, contrary to past practice, bugs should not be targeted to milestones merely because a developer intends to deliver the bugfix for that milestone, but instead should be targeted only when, in the developer's opinion, leaving the bug unfixed for the milestone release would cause the milestone to fail the corresponding release criteria.
This change is a response to the large number of bugs that have in the past been targeted for a milestone but not delivered, resulting in additional milestone triage work to move bugs forward to the next milestone. It is not intended to imply that non-milestoned bugs are of lower priority or to discourage developers from working on non-milestoned bugs during the early stages of the release cycle; developers should continue to strive to deliver fixes for important bugs early in the release cycle wherever applicable, but without using individual milestone targets to track these bugs.
Release nominations
To indicate that a bug should be fixed prior to the final release, the bug should be nominated for release using the "target to release" option in Launchpad, either in addition to or instead of a milestone target. 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 nominated (and accepted) 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 finding someone to do the work on the bug.
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.
Personal TODO lists
It is useful to have a list of prioritized bugs for an individual developer, for the benefit of both the developer and the release team. It is recommended that developers use the "In Progress" status for this purpose. Combined with the existing bug assignments and release nominations, it is believed this will serve the needs of developers to track their release "TODO" lists within Launchpad.