On this page, you will learn how a bug is tracked in Bugzilla.
A bug is entering the bug tracking system and then walks through a number of states that are set by the maintainers/developers. Hence at any point in time the bug is reviewable by everyone.
[New bug report]
+
| +---------------+ +---------------+
+-->+ NEW | +------->+ ASSIGNED |
+-------+-------+ | +-------+-------+
| | |
v | v
[review by | +-------+-------+
triage team] | | ON_DEV |
+ | +-------+-------+
| | |
____v____ | v
/ \ | [send changes
/ to be \ no | to repository]
\ closed? /+-------+ +
\_________/ |
+ v
yes | +-------+-------+
| | MODIFIED |
| +-------+-------+
| |
v v
+-------+-------+ +-------+-------+
| CLOSED | | ON_QA |
+-------+-------+ +-------+-------+
| |
v v
+---------+---------+ +-------+-------+
| RESOLUTIONs | | VERIFIED |
| duplicate | +-------+-------+
| insufficent data | |
| not a bug | v
| wont fix | +-------+-------+
| cant fix | | CLOSED |
| works for me | +-------+-------+
| upstream | |
| errata | v
+-------------------+ +-------+-------+
| RESOLUTIONs |
| fixed |
+---------------+
Note: STATE/STATUS is in all caps
When a bug is reported, it starts out in the NEW state. The triage team will review bugs when created and change the report to one of the following:
The needinfo flag is set when more information is needed from the reporter of the bug. It can be set directly after the start or if the maintainer/assignee is missing adequate information to move the bug towards resolution.
To set needinfo, look for Flags:, click set flags, and click +.
If the required information is received the bug status is changed to ASSIGNED. If flagged as needinfo for more than 30 continuous days, use the following message:
The information we've requested above is required in order to review this problem report further and diagnose or fix the issue if it is still present. Since it has been thirty days or more since we first requested additional information, we're assuming the problem is either no longer present in the current release, or that there is no longer any interest in tracking the problem.
Set the status to CLOSED and the resolution to INSUFFICIENT_DATA.
If you still experience this problem after updating to our latest release and can provide the information previously requested, please feel free to reopen the bug report.
When all of the following required information is correctly set, the bug may be changed to ASSIGNED state:
---
at the top of the list---
if none of those components fit the situationThe reporter has also included one or more of the following (as applicable):
In the ASSIGNED state, the bug is waiting until the assignee starts working an it (and he may optionally change the state to ON_DEV).
The ON_DEV state may be used when there is actively worked on a solution for this bug. It is not required to set this state, but useful when a group of maintainers is assigned to this bug.
When a maintainer has a fix for a bug checked into the source repository the bug should be placed in the MODIFIED state. This is an indication that the fix is checked into the Source Code Management (SCM) and has potentially been submitted to be built in a new package. Adding a link to package in PBS is very helpful for adventuresome testers and the original bug reporter to verify the fix.
A bug automatically transitions to this state when an updated package is submitted to the testing repository. This tells the bug reporter that a fix for the bug is available and that they should test the package. After testing the package the bug tester or original reporter should put feedback in PBS and add a comment to Bugzilla.
The bug should be changed to VERIFIED when the QA process is finished and the change actually fixes the bug. A fix is considered confirmed due to user's comments in Bugzilla and PBS.
Once a bug has been fixed and included in a new package it should be closed.
However, there are some resolutions available to be selected besides FIXED:
Older Revisions • July 16 at 5:24 pm • Jon