Differences in Revisions: Bug workflow

»
Fix the ASCII art - the image is not editable
# Bug workflow
 
On this page, you will learn how a bug is tracked in Bugzilla.
 
## Sketch of the workflow
 
On the image below, you will see how a bug is entering the bug tracking system and is then walking through a number of states that are set by the maintainers/developers. Hence at any point in time, it is comprehensible for everybody what has been done with the bug report.
 
```text
[optional]
|---------------| |---------------| ...................
|---------------| |---------------| ...................
[New bug report]-->| NEW |------[Review by some maintainer]---->| ASSIGNED |------------| .
|---------------| | |---------------| . | .
|---------------| | |---------------| . | .
| ^ | . [Someone starts .
|----------------------| /|\ | . working on it] .
|----------------------| /|\ | . working on it] .
| | | | . .
| | | | . .
| \|/ |-----------------| | .|---------------|.
| \|/ |-----------------| | .|---------------|.
| ° | | .| ON_DEV |.
| ° | | .| ON_DEV |.
\|/ |---------------| | .|---------------|.
\|/ |---------------| | .|---------------|.
° | needinfo | | . | .
° | needinfo | | . | .
|---------------| |---------------| | ..........|........
|---------------| |---------------| | ..........|........
| *CLOSED* | | | |
|---------------| | [Changes checked into source repository]
| fixed |<-------------| |
| fixed |<-------------| |
| duplicate | (INSUFFICIENT_DATA) |
| duplicate | (INSUFFICIENT_DATA) |
| wontfix | |
| wontfix | |
| ... | |
| ... | |
|---------------| \|/
|---------------| \|/
^ °
^ °
/|\ |---------------| |---------------| |---------------|
/|\ |---------------| |---------------| |---------------|
|---------------| VERIFIED |<---| ON_QA |<---| MODIFIED |
|---------------| VERIFIED |<---| ON_QA |<---| MODIFIED |
|---------------| |---------------| |---------------|
|---------------| |---------------| |---------------|
```
 
 
 
## Bug states and resolutions
 
### NEW
 
When a bug is reported, it starts out in the **NEW** state. The triage team will pick up bugs in this state and change the status to one of the following:
 
* **NEEDINFO**: More information will be needed from the reporter.
* **CLOSED**: Duplicate, not a bug, or anything else that makes the bug totally invalid.
 
 
### Needinfo
 
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.
 
From here, the bug may be changed to **ASSIGNED** if the required criteria are fulfilled or to **CLOSED INSUFFICIENT_DATA** when the requested information has not been provided or it has been flagged **needinfo** for more than 30 continuous days. Use the following message:
 
#### 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.
 
Setting status to "CLOSED: 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.
 
 
### ASSIGNED
 
When all of the following required information is correctly set, the bug may be changed to **ASSIGNED** state.
 
* the correct*product*
* the correct*component*
* enough information for the package maintainer to investigate the issue
 
The reporter has also included one or more of the following (as applicable):
 
* clear steps describing how the bug occurred
* clear steps describing how to reproduce the problem
* stack trace for a crasher
* various log files
 
FIXME Maybe we could make an addition page with instructions on how to collect data for bug reports. Like AVC messages for SELinux, kernel dumps, etc.?
 
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**).
 
### 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.
 
### MODIFIED
 
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 SCM and has potentially been submitted to be built in a new package. Adding a link to package in [PBS](https://pakfire.ipfire.org/) is very helpful for adventuresome testers and the original bug reporter to verify the fix.
 
### ON_QA
 
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.
 
### VERIFIED
 
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.
 
### CLOSED
 
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**:
 
* Bugs can be closed as **DUPLICATE** by a maintainer at any point when they are identified as a duplicate of another bug.
* Bugs can be closed as **INSUFFICIENT_DATA** by a triager or maintainer if it seems impossible or very unlikely that the reporter will be willing or able to provide sufficient information.
* Bugs can be closed as **NOTABUG** if it becomes clear they are not truly a bug in IPFire (e.g. the reporter's hardware is malfunctioning), or by the maintainer at any point.
* The resolutions **CANTFIX**, **WONTFIX**, and **WORKSFORME** are for use by maintainers only, and are self-explanatory.
* Also there is **ERRATA** which marks bug that actually are no bugs.
* A bug should be closed as **UPSTREAM**, when a solution is worked by the upstream project. Please add a comment and reference.