Bug workflow

On this page, you will learn how a bug is tracked in Bugzilla.

Workflow sketch

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

Bug states and resolutions

NEW

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:

needinfo: More information will be needed from the reporter.
CLOSED: Duplicate, not a bug, or anything else that makes the bug totally invalid.

needinfo Flag

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.

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:
- for now and for IPFire 2.x always choose --- at the top of the list
- for IPFire 3 choose one of listed components or --- if none of those components fit the situation
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

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 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.

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.