Target Management Bug Process
This documents how the Target Management Project uses
Bugzilla to handle
bug reports, enhancement requests, patches etc. It covers
basic lifecycle information and clarifications for how to
use the various Bugzilla fields.
Interesting Bugzilla Queries
Planning and feature work
Bugfix and Contribution work
Bugs assigned to committers or contributors
QA queries
Reports for Release Review
Reports and queries needed less frequently
Bug Lifecycle
Everybody - users and developers - may apply for a
Bugzilla account
and submit bug reports or enhancement requests.
Once the bug report is filed, contributors and committers
work on it, including updates to bug status. All users
may contribute to the discussion by adding comments (but
typically not change the status fields).
The Eclipse Process Guidelines contain some good
information and a handy diagram for understanding the
lifecycle of an issue in Bugzilla.
How to defer bugs
In our
Committer Meeting on 23-May 2006 we decided on the following strategies for deferring bugs.
This was later amended according to
bug 178923 by adding a "Future" milestone. The main goal of these guidelines is
to be able and write good bugzilla queries that allow us avoid looking
at deferred bugs again later. So here is the process:
- Set the Priority according to personal judgement of importance:
Even bugs with a high priority can be deferred to an upcoming release
if time just dont permit fixing them.
- Set Resolved, Resolution=INVALID for requests that do not make
sense.
- Set Resolved, Resolution=WONTFIX for bugs that we will supposedly
never address e.g. because there is a suitable workaround or the effort is
just too high although the request makes sense.
- Set Target Milestone=Future for bugs that make sense but are
too much effort for the current release. They should be triaged again for
the next release, and perhaps be documented as known limitations in
the release notes. Such bugs will typically be in NEW state and assigned
to dsdp.tm.rse-inbox@eclipse.org or dsdp.tm.core-inbox@eclipse.org.
- Assign the bug to a developer and set the target milestone
for bugs that we want to address in the current release cycle.
- Assign bugs to the org.eclipse.tm.rse-inbox@eclipse.org with
the default target milestone="---" if you have no idea what to do with
a request and also dont know who else could handle it. It will triaged
again by all committers together in the next committer meeting. Please
do this as a last resort, though, since looking multiple times at the
same bug is unnecessary effort; and add a comment with your thoughts
on the bug.
How to verify and close
- Bugs that are set RESOLVED are candidates for verification.
- Ideally, the person who filed a bug should also verify it and set
it to VERIFIED if OK.
- During the final release test cycle, all RESOLVED and even VERIFIED
bugs will be checked again. If they pass the test, they will be set
CLOSED.
- Enhancement requests and applied patches can also be set CLOSED
right after checkin, especially if they do not apply to testable
product functionality but rather some code cleanliness.
Clarification of Fields
- Platform and OS: These should be set by the submitter
of a bug to describe the platform and OS on which a bug was detected.
This does not mean that the bug would occur only on this particular
platform.
- Use Platform All only if you have good evidence that a
bug actually occurs on all platforms.
- When you are sure that a bug occurs only on a particular
platform, please indicate so in the Summary field by adding
a tag lice [mac] or [linux]
- Summary field: We use tags in square brackets to indicate certain
categories of bugs. Please use the following tags as indication:
- [api] - API problem (typically not user visible)
- [apidoc] - API documentation issue
- [doc] - User documentation issue
- [linux] - Bug occurs on Linux only
- [mac] - Bug occurs on MacOS X only
- [persistence] - RSE Persistency support issue
- [ssh] - Bug occurs on ssh subsystem only
- [team] - RSE Team support issue
- [updating] - Problem with update status of items in RSE
- [windows] - Bug occurs on Windows only
Submitting a Patch
Every user may submit a patch for an issue he finds, by attaching
the code to the corresponding Bugzilla item. Submitting patches turns
the ordinary user into a contributor, for which he or she will be
given credit to.
Please attach only patches on bugzilla for which you have the right
to attach them. In the typical case, if you put a legal notice like
the following alongside your contribution, it will speed up the
contribution process:
Legal Message: I, {name}, declare that I developed attached code from
scratch, without referencing any 3rd party materials except material
licensed under the EPL. {I am authorized by my employer to make this
contribution under the EPL.}
If this message does not apply for you (e.g. because you did use 3rd party
materials), please contact the
dsdp-tm-dev@eclipse.org Developer Mailing List to seek assistance of
a committer.
Once your contribution is attached to Bugzilla, a committer will pick it
up and follow the
Committer HOWTO guidelines to merge your contribution.
code without being allowed to do so by the copyright owner).
Testing, tips and tricks for bug finding
