RCBugTargetting
|
Size: 4127
Comment: "personal TODO lists"
|
Size: 3027
Comment: revamp based on discussions with Scott.
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 7: | Line 7: |
| == 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. |
|
| Line 15: | Line 9: |
| 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. | To indicate that a bug should be fixed prior to the final release, the bug should be nominated using the "target to release" option in Launchpad. 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. |
| Line 19: | Line 13: |
| 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. | 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. |
| Line 23: | Line 17: |
| == Personal TODO lists == | == Milestones == |
| Line 25: | Line 19: |
| 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. | 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. |
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, the bug should be nominated using the "target to release" option in Launchpad. 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.
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.
RCBugTargetting (last edited 2012-09-13 20:29:29 by brian-murray)