Difference between revisions of "CDT/Obsolete/Bugs"

Revision as of 20:05, 2 January 2009

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.

Bug Queries