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 (New page: == Bug Life Cycle == === How bugs are created === Everybody - users and developers - may apply for a [http://bugs.eclipse.org/bugs Bugzilla account] and submit bug reports or enhancement ...) |
m (→Bug Life Cycle) |
||
| Line 1: | Line 1: | ||
== Bug Life Cycle == | == Bug Life Cycle == | ||
| − | + | [[Image:CDT_Bug-life_cycle.png]] | |
| − | + | ||
| − | + | ||
| − | |||
| − | === | + | 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. |
| − | # Normally a bug should be created and assigned to the | + | |
| + | === Filing === | ||
| + | Everybody - users and developers - may apply for a [http://bugs.eclipse.org/bugs Bugzilla account] and [http://bugs.eclipse.org/bugs/enter_bug.cgi?product=CDT 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 [http://bugs.eclipse.org/bugs/page.cgi?id=fields.html#resolution resolutions] : DUPLICATE, INVALID, WONTFIX, NOT_ECLIPSE, WORKSFORME. | ||
| + | * If the bug doesn't contain enough information to determine what to do with it, a "needinfo" [http://bugs.eclipse.org/bugs/describekeywords.cgi keyword] will be added along with a comment on what need additional information is needed. | ||
| + | |||
| + | === Fixing === | ||
| + | A committer who is ... | ||
| + | |||
| + | # Normally a bug should be created and assigned to the appropriate component inbox: (e.g. cdt-debug-inbox@eclipse.org). However, when a developer creates a bug that he/she intends to work on, he may set the "Assigned To" field to himself. | ||
| + | |||
| + | The project is configured to add dd.general-inbox@eclipse.org to bug's CC list, so all inbox listeners will get notified of the bug anyhow. | ||
#* If the bug is in the inbox, the component owner, which is normally the leader of the sub-project owns the component, confirms that the bug is valid and assigns it to a committer or contributor. | #* If the bug is in the inbox, the component owner, which is normally the leader of the sub-project owns the component, confirms that the bug is valid and assigns it to a committer or contributor. | ||
#* Alternatively, if a contributor created the bug for an issue that was discovered and immediately fixed, the contributor should assign the bug to himself. | #* Alternatively, if a contributor created the bug for an issue that was discovered and immediately fixed, the contributor should assign the bug to himself. | ||
Revision as of 15:47, 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 is ...
- Normally a bug should be created and assigned to the appropriate component inbox: (e.g. cdt-debug-inbox@eclipse.org). However, when a developer creates a bug that he/she intends to work on, he may set the "Assigned To" field to himself.
The project is configured to add dd.general-inbox@eclipse.org to bug's CC list, so all inbox listeners will get notified of the bug anyhow.
- If the bug is in the inbox, the component owner, which is normally the leader of the sub-project owns the component, confirms that the bug is valid and assigns it to a committer or contributor.
- Alternatively, if a contributor created the bug for an issue that was discovered and immediately fixed, the contributor should assign the bug to himself.
- Plan items and other composite enhancements can stay assigned to the inbox, but have their state changed to ASSIGNED when a commitment is made to fix them.
- When the contributor can commit to a fixing a bug, he changes the state to ASSIGNED and sets a target milestone.
How bugs are FIXED and VERIFIED
- When a committer or contributor has completed fixing the bug, he should post a patch with the fix to the bug.
- A committer commits the changes to CVS. A contributor can request a committer to apply the patch.
- The committer changes the "Assigned To" field of the bug to another committer who is to review the fix.
- The committer fixing the bug changes the bug status to FIXED.
- The reviewer should review the changes and optionally confirm program behavior and mark the bug as VERIFIED.
How bugs are CLOSED
- With each milestone build, the VERIFIED bugs are logged in build notes and 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.