Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "RAP/Bugzilla"
< RAP
m (→Common Bugzilla Queries) |
|||
| Line 21: | Line 21: | ||
== Priorities == | == Priorities == | ||
| − | We use | + | The priority attribute is set by the RAP team. |
| + | We use this attribute to mark those bugs that have to be fixed no matter what. | ||
| + | Priorities are used as follows: | ||
* P1: Critical. Should be fixed within the current milestone. | * P1: Critical. Should be fixed within the current milestone. | ||
| Line 27: | Line 29: | ||
* P3: Normal bug (default). | * P3: Normal bug (default). | ||
* P5: It's a valid bug, but will not fix it in the foreseeable future. | * P5: It's a valid bug, but will not fix it in the foreseeable future. | ||
| + | |||
| + | The priority of a bug is often debatable. | ||
| + | Here are some indications that a bug should be handled with priority: | ||
| + | |||
| + | * An issue that leads to crashes should be fixed as soon as possible (P1). | ||
| + | * Security problems should also be handled with priority. | ||
| + | * Regression have to be fixed in the next release (or next milestone depending on their relevance) to ensure that existing applications can upgrade to new versions. The same is true for performance degradations. | ||
| + | * API-relevant issues, e.g. API changes that have become necessary because of changes in the development stream, have to be closed before API freeze. | ||
| + | * If an issue affects every application, not just those that use certain combinations of features, this is an indication for higher priority. | ||
| + | |||
| + | Remember that we only have those 5 priorities. If we prioritize too many bugs, the system becomes useless. | ||
== Status Whiteboard == | == Status Whiteboard == | ||
Revision as of 13:00, 12 March 2012
Contents
Bugzilla Guidelines for RAP Committers
Workflow
- when triaging bugs:
- set status to assigned if the bugs appears valid
- set priority if needed (see section below)
- when start working on a bug
- assign it to yourself
- copy others that might be interested
- when stop working on a bug
- reassign to inbox to broadcast subsequent changes
- when closing a bug
- reassign to inbox before closing to broadcast the change
- shortly describe the problem/solution
- set target milestone for fixed bugs
Priorities
The priority attribute is set by the RAP team. We use this attribute to mark those bugs that have to be fixed no matter what. Priorities are used as follows:
- P1: Critical. Should be fixed within the current milestone.
- P2: Release critical. Should be fixed before the release.
- P3: Normal bug (default).
- P5: It's a valid bug, but will not fix it in the foreseeable future.
The priority of a bug is often debatable. Here are some indications that a bug should be handled with priority:
- An issue that leads to crashes should be fixed as soon as possible (P1).
- Security problems should also be handled with priority.
- Regression have to be fixed in the next release (or next milestone depending on their relevance) to ensure that existing applications can upgrade to new versions. The same is true for performance degradations.
- API-relevant issues, e.g. API changes that have become necessary because of changes in the development stream, have to be closed before API freeze.
- If an issue affects every application, not just those that use certain combinations of features, this is an indication for higher priority.
Remember that we only have those 5 priorities. If we prioritize too many bugs, the system becomes useless.
Status Whiteboard
RAP uses the 'Status Whiteboard' field to label bugs with:
- srNNN used for tagging bugs that are fixed in the maintenance branch of the last release. See Backporting fixes for service releases
- srNNN? used for tagging bugs should be backported to the maintenance branch of the last release. See Backporting fixes for service releases
qx-openobsolete. Has been used for bugs that depend on an unresolved qooxdoo bug. The bug id of the qooxdoo bug should be found in one of the comments.qx-closed: obsolete. Has been used once a blocking qooxdoo bug was resolved (see qx-open). This way, all unresolved RAP bugs could be identified that should be solved after migrating to the next qooxdoo service release.extend-rwtobsolete. Has been used only for the 1.2 plan. All bugs labeled that way will be shown in the Reduce the gap between RWT and SWT theme.
Keywords
Please refer to the description of Keywords used in Eclipse Bugzilla.
Status and Resolution
Please read this document for a list of statuses and their use.