# A Bug's Life Cycle

The status and resolution field define and track the life cycle of a bug.

# STATUS

# RESOLUTION

The status field indicates the general health of a bug. Only certain status transitions are allowed. | The resolution field indicates what happened to this bug.

NEW
  This bug has recently been added to the assignee's list of bugs and must be processed. Bugs in this state may be accepted, and become ASSIGNED, passed on to someone else, and remain NEW, or resolved and marked RESOLVED.
ASSIGNED
  This bug is not yet resolved, but is assigned to the proper person. From here bugs can be given to another person and become NEW, or resolved and become RESOLVED.
REOPENED
  This bug was once resolved, but the resolution was deemed incorrect. For example, a WORKSFORME bug is REOPENED when more information shows up and the bug is now reproducible. From here bugs are either marked ASSIGNED or RESOLVED.

  No resolution yet. All bugs which are NEW or ASSIGNED have the resolution set to blank. All other bugs will be marked with one of the following resolutions.

RESOLVED
  A resolution has been taken, and it is awaiting verification by QA. From here bugs are either re-opened and become REOPENED, are marked VERIFIED, or are closed for good and marked CLOSED.
VERIFIED
  QA has looked at the bug and the resolution and agrees that the appropriate resolution has been taken. Bugs remain in this state until the product they were reported against actually ship, at which point the become CLOSED.
CLOSED
  The bug is considered dead, the resolution is correct. Any zombie bugs who choose to walk the earth again must do so by becoming REOPENED.

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.
LATER
  The problem described is a bug which will not be fixed in this version of the product.
REMIND
  The problem described is a bug which will probably not be fixed in this version of the product, but might still be.
DUPLICATE
  The problem is a duplicate of an existing bug. Marking a bug duplicate requires the bug# of the duplicating bug and will at least put that bug number in the description field.
WORKSFORME
  All attempts at reproducing this bug were futile, reading the code produces no clues as to why this behavior would occur. If more information appears later, please re-assign the bug, for now, file it.

# Other Fields

## Severity

This field describes the impact of a bug.

Critical | crashes, loss of data, severe memory leak
Major | major loss of function
Minor | minor loss of function, or other problem where easy workaround is present
Trivial | cosmetic problem like misspelt words or misaligned text
Enhancement | Request for enhancement

## Priority

This field describes the importance and order in which a bug should be fixed. The available priorities are:

P1 | Most important
P2 |
P3 |
P4 |
P5 | Least important

## Area

This is the general area which is covered by the bug report. This allows bugs to migrate over to testing, but not show up on the "daily bug list". Most bugs should have area set to CODE. Legal values include:

- CODE
- JAVA
- TEST
- UI
- BUILD
- PERF
- i18n (internationalization)
- l10n (localization)

## Platform

This is the hardware platform against which the bug was reported. Legal platforms include:

- All (happens on all platform; cross-platform bug)
- Macintosh
- PC
- Sun
- HP

Note: Selecting the option "All" does not select bugs assigned against all platforms. It merely selects bugs that occur on all platforms.

## Assigned To

This is the person in charge of resolving the bug. Every time this field changes, the status changes to NEW to make it easy to see which new bugs have appeared on a person's list.

List of module owners.

The default status for queries is set to NEW, ASSIGNED and REOPENED. When searching for bugs that have been resolved or verified, remember to set the status field appropriately.

Last modified: Wed Dec 2 14:08:58 1998