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 "CDT/Obsolete/Bugs"
m (→Bug Life Cycle) |
m (→Bug Life Cycle) |
||
| Line 1: | Line 1: | ||
== Bug Life Cycle == | == Bug Life Cycle == | ||
| + | All users may contribute to the discussion by adding comments (but typically not change the status fields). The Eclipse Process Guidelines contains more general information and diagram on bug lifecycle [http://www.eclipse.org/projects/dev_process/bugzilla-use.php information and a handy diagram]. Once the bug report is filed, contributors and committers work on it, including updates to bug status. | ||
| + | |||
[[Image:CDT_Bug-life_cycle.png]] | [[Image:CDT_Bug-life_cycle.png]] | ||
| − | |||
| − | |||
| − | |||
=== Filing === | === Filing === | ||
| Line 15: | Line 14: | ||
=== Fixing === | === Fixing === | ||
| − | A committer who | + | * A committer who intends to fix a given bug, takes the bug by changing the Assigned to: field, changes its status to ASSIGNED and sets the target milestone when he intends to commit the fix. |
| − | + | ||
| − | + | ||
| − | + | === Reviewing === | |
| − | + | * Before committing the fix, the committer should create a patch with the changes that are applied to fix the bug. This patch should be attached to the bug with the fix comment. | |
| − | + | * The committer should request for another committer or contributor to review the bug. This is done by adding a review flag to the bug with the name of the developer being requested to review the bug, or of the component inbox. | |
| − | + | * Upon reviewing the fix, the reviewing committer can change the review flag to a "+" or "-". The review can be omitted if the component has only one active developer. | |
| − | + | ||
| − | === | + | === Verifying === |
| − | + | * Once the bug is fixed, the user that requested the bug to be fixed, should download the build which includes the fix and try it. If the issue is indeed addressed, the user should mark the bug as VERIFIED. | |
| − | + | * Alternatively, during a manual milestone testing cycle, a tester may also confirm that the bug is fixed and mark is VERIFIED. | |
| − | + | ||
| − | + | ||
| − | + | ||
=== How bugs are CLOSED === | === How bugs are CLOSED === | ||
| − | + | * When a release is shipped, all bugs filed in that release and resolved with resolutions: VERIFIED, DUPLICATE, WONTFIX, NOT_ECLIPSE, WORKSFORME are marked as CLOSED. | |
| + | * Also when a release is shipped, all bugs filed in previous release, with resolution FIXED, will be marked as CLOSED. | ||
=== Bugs in maintenance release | === Bugs in maintenance release | ||
Revision as of 19:06, 2 January 2009
Contents
Bug Life Cycle
All users may contribute to the discussion by adding comments (but typically not change the status fields). The Eclipse Process Guidelines contains more general information and diagram on bug lifecycle information and a handy diagram. Once the bug report is filed, contributors and committers work on it, including updates to bug status.
Filing
Everybody - users and developers - may apply for a Bugzilla account and submit bug reports or enhancement requests. Bugs are created in NEW state and are assigned to the selected compoenent's inbox email (e.g. cdt-debug-inbox@eclipse.org). Users and developers who would like to be notified of all new bugs on a component can configure their bugzilla preferences to watch the component inbox.
Triage
Component owners are ultimately responsible for triaging bugs assigned to their component, although anyone is welcome to help with this task. Bugs in NEW state are reviewed to determine whether the bug is valid and not a duplicate of an existing bug.
- If the bug is valid, the developer changes the bug state to ASSIGNED, while leaving the "Assigned To:" field set to the component inbox email.
- If the bug is determined not to require any further action, it's state is immediately changed to RESOLVED, with one of the following resolutions : DUPLICATE, INVALID, WONTFIX, NOT_ECLIPSE, WORKSFORME.
- If the bug doesn't contain enough information to determine what to do with it, a "needinfo" keyword will be added along with a comment on what need additional information is needed.
Fixing
- A committer who intends to fix a given bug, takes the bug by changing the Assigned to: field, changes its status to ASSIGNED and sets the target milestone when he intends to commit the fix.
Reviewing
- Before committing the fix, the committer should create a patch with the changes that are applied to fix the bug. This patch should be attached to the bug with the fix comment.
- The committer should request for another committer or contributor to review the bug. This is done by adding a review flag to the bug with the name of the developer being requested to review the bug, or of the component inbox.
- Upon reviewing the fix, the reviewing committer can change the review flag to a "+" or "-". The review can be omitted if the component has only one active developer.
Verifying
- Once the bug is fixed, the user that requested the bug to be fixed, should download the build which includes the fix and try it. If the issue is indeed addressed, the user should mark the bug as VERIFIED.
- Alternatively, during a manual milestone testing cycle, a tester may also confirm that the bug is fixed and mark is VERIFIED.
How bugs are CLOSED
- When a release is shipped, all bugs filed in that release and resolved with resolutions: VERIFIED, DUPLICATE, WONTFIX, NOT_ECLIPSE, WORKSFORME are marked as CLOSED.
- Also when a release is shipped, all bugs filed in previous release, with resolution FIXED, will be marked as CLOSED.
=== Bugs in maintenance release
- We will only have maintenance releases for latest major release.
- If a bug is determined to be severe enough to be addressed in the maintenance release, that bug is to be re-opened and targeted for that release.
- Part of the bug review is to make sure that the fix is applied to both branches.