Skip to main content

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.

Jump to: navigation, search

WTP Bugs, Workflow and Conventions

Revision as of 02:40, 24 August 2006 by David williams.acm.org (Talk | contribs) (initial content)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Introduction and Purpose of this document

Our WTP Bugs are tracked in the Eclipse bugzilla system.

There is a main "Web Tools" classification category, with, currently, three subclassifications (called "Products" in bugzilla): Web Tools proper, for released components; and others for subprojects or components that are incubating (currently AFT, and Java Server Faces, and soon JPA).

The purpose of this document is not to repeat or contradict the normal bugzilla help documentation, but simply to supplement it, and be explicit about conventions we in WTP use that are not part of the bugzilla system per se.

Workflow

The following are a guide to the day to day work that component leads and bug owners follow.

When a bug is first reported, it is put in the "inbox" of the component that was specified.

Relatively soon after that (e.g. within one week) component owners should do initial triage, and specify a specific person to own the bug. This initial triage is just an acknowledgement that it appears to be a valid report, and that it is in the right component. Things like priority might be assigned at this time, but, that can also be done later.

Based on severity, priority, and the bug owner's time constraints :( the owner will further triage or investigate the bug, ask clarifying questions, try to reproduce, etc.

Once someone starts actively working on a bug, to produce a fix, they should put the bug in the "assigned" state. That way, other committers know they should not also work on it. If a bug is not in an assigned state, other committers are free to assume ownership of a bug, if, for example, it is related to other bugs they are working on, or, they happen to know about that area of code due to working on it before, etc.

The target field should be assigned once the owner is relatively confident the fix will actually appear in that milestone. In other words, its not for long term planning, but more for short term planning and historical checking of "what's fixed" in a particular milestone.

Note: the 'version' field is considered too ambiguous and used too inconsistently to be of much value ... but, there is a pattern that is supposed to be followed. When someone reports a bug, they are supposed to mark the version as the version they found the bug in, as close as possible (but, they usually need to give the exact build id of the version they were using, to be meaningful). Then, when fixed, the bug owner should change the version to the version the bug was fixed in).

Conventions of embellishments

Status Whiteboard: This is pretty much for each component to use as they see fit ... usually marking short term notes of "needs review", etc., pretty much characterized as communication with other team members.

Keywords: committers should set these "built in" keywords accurately: (e.g. 'api', 'performance'), and if there is a built in keyword, there is no need to be redundant and specify the same thing as a summary keyword.

</b>Summary keywords:</b> These are the words or phrases contained in square brackets in the bug's summary line. Sometimes, components will use their own conventions to allow "sub categories" of bugs for their own book keeping (for example, "[project creation]"). But, the following list are project-wide conventions. Its not necessarily exhaustive, but we'll try to keep this list accurate. Note: in the event more than one summary keyword is desired, they should each be contained in square brackets, such as "[hotbug][project creation]". (Their order not being significant, and case is not significant).

[internal api]
this marks a bug report where our WTP code calls a non-api method of a prerequisite class.
[API Request]
this marks an enhancement request where the originator is letting us know that to accomplish some function/extension, they need to use some of our internal non-API methods.

Back to the top