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
Contributions and IP Review
Indigo contributions candidates: Non-committer attachments that are not flagged iplog+ and not an image, on any bug modified since 1-Jun-2010.
- Use this to find additional candidates to mark iplog+, then use the IP Log Tool to filter-out bogus iplog+
- Also helpful to generally find contributions not yet attended to (for follow-up with the submitter)
- This query does not find code submitted as a bugzilla comment - these are very rare, Wayne's contribution review tool might find them
Planning and feature work
- TM and RSE Plan Items
- TM and RSE unplanned open API bugs (without any plan items as "blocks" references)
- TM and RSE all open API bugs
- TM and RSE new bugs not yet triaged
- TM and RSE 2.0.4 assigned bugs
- TM and RSE open 3.0RC2 assigned bugs
- TM and RSE open 3.0 assigned bugs
- TM and RSE Bugs related to PII
- Terminal open bugs
- TM and RSE bugs deferred to the future
Bugfix and Contribution work
- TM and RSE open severe bugs (major, critical, blocker)
- TM and RSE open hi-pri bugs (major, critical, blocker, P1 or P2)
- TM and RSE open bugs with patches attached
- TM and RSE open current bugs (bugs which changed last week, except deferred with Target Milestone="---" or Target Milestone="Future")
- TM and RSE bugs fixed last week (important for verification!)
Bugs assigned to committers or contributors
- TM and RSE Assigned to Inbox
- TM and RSE
Report: All Open, Assignee vs. Priority - Helps to see who is working on high priority issues;
allows to pick a particular assignee in order to create "assigned to me" reports as follows
Company TM Open Assigned to NEW for Changed last week for IBM david_dykstal david_dykstal david_dykstal dmcknigh dmcknigh dmcknigh kjdoyle kjdoyle kjdoyle xuanchen xuanchen xuanchen Wind River martin.oberhuber martin.oberhuber martin.oberhuber uwe.stieber uwe.stieber uwe.stieber michael.scharf michael.scharf michael.scharf eugene.tarassov eugene.tarassov eugene.tarassov felix.burton felix.burton felix.burton ProSyst r_gerganov r_gerganov r_gerganov Private javier.montalvoorus javier.montalvoorus javier.montalvoorus Contributors ewa.matejska ewa.matejska ewa.matejska ykuo ykuo ykuo adushistova adushistova adushistova lothar.werzinger lothar.werzinger lothar.werzinger rupenm rupenm rupenm takuya takuya takuya
Reports for Release Review
- TM Report: All 2.x bugs vs. Target Milestone
- TM Report: All 3.x bugs vs. Target Milestone
- TM Report: All Bugs, Severity vs. Status
- TM Report: All Bugs, Severity vs. Resolution
Reports and queries needed less frequently
- TM Report: User-submitted Open Bugs (Committer-submitted bugs filtered out)
- TM Report: All Open, Reporter vs. Severity - Helps to see who found the most important bugs
- TM Report: All Bugs, Reporter vs. Resolution - Helps to find reporters who frequently make invalid or duplicate reports
- TM All Open Bugs
- TM All Fixed Bugs
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 email@example.com or firstname.lastname@example.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 email@example.com 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
- 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 PatchEvery 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: If this message does not apply for you (e.g. because you did use 3rd party materials), please contact the firstname.lastname@example.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).