- UNCONFIRMED
-
This bug has recently been added to the database.
Nobody has confirmed that this bug is valid. Users
who have the "canconfirm" permission set may confirm
this bug, changing its state to
CONFIRMED.
Or, it may be directly resolved and marked
RESOLVED.
- CONFIRMED
-
This bug is valid and has recently been filed.
Bugs in this state become
IN_PROGRESS
when somebody is working on them, or become resolved and marked
RESOLVED.
- IN_PROGRESS
-
This bug is not yet resolved, but is assigned to the
proper person who is working on the bug. From here,
bugs can be given to another person and become
CONFIRMED, or
resolved and become
RESOLVED.
|
No resolution yet. All bugs which are in one of
these "open" states have no resolution set.
|
- RESOLVED
-
A resolution has been performed, and it is awaiting verification by
QA. From here bugs are either reopened and given some
open status, or are verified by an impacted user or QA and marked
VERIFIED.
- VERIFIED
-
QA has looked at the bug and the resolution and
agrees that the appropriate resolution has been taken. This is
the final status for bugs.
|
- FIXED
-
A fix for this bug is checked into the tree and
tested.
- INVALID
-
The problem described is not a bug.
- WONTFIX
-
The problem described is a bug which will never be
fixed.
- DUPLICATE
-
The problem is a duplicate of an existing bug.
When a bug is marked as a
DUPLICATE,
you will see which bug it is a duplicate of,
next to the resolution.
- WORKSFORME
-
All attempts at reproducing this bug were futile,
and reading the code produces no clues as to why the described
behavior would occur. If more information appears later,
the bug can be reopened.
- CANTFIX
-
Fixing this bug is not possible, and the reasoning
should be detailed by the closer. Generally speaking, fixing thebug might be technically unfeasible, require an
extraordinary (unreasonable) amount of effort, be disallowed for
legal/social reasons, or not within bounds of the current framework.
If circumstances change later on that affect the justification, thebug can be reopened and reconsidered.
- NEEDINFO
-
Before investigation can proceed further, the reporter needs to
provide more information. This often includes clarification of
already posted details, adding missing log files, or running some
tests to help debug the situation. Once the requested information
has been provided, the bug should be re-opened. This
status is frequently used when the expectation is the submitter
has disappeared and won't follow up, or to help clear out open
reports that still need triaging.
- TEST-REQUEST
-
The bug is thought to be fixed, but we would like
someone who is affected to verify the fix. If the bug
is not actually fixed, then the report should be reopened and more
details posted (explaining why people believe the bug
is not actually fixed).
- UPSTREAM
-
The requested bug is considered to be out of the purview
of the distro and should be submitted/discussed directly with the
respective upstream project. This could include a number of things
such as changing default configuration options or behavior, adding
new options or functionality, or deleting support for older systems.
- OBSOLETE
-
Due to a variety of reasons, the bug as reported is no
longer relevant. It might apply to older versions of a package and
the newer versions rewrote (implicitly fixing) the related code, or
perhaps support was dropped entirely.
- PKGREMOVED
-
The bug is no longer relevant because the affected
package was removed from the tree. However, it may become
relevant again if the package is reintroduced.
|
