This bug state flow came as a result of the bug triage relaunch that started in January 2008. This work flow was approved at the meeting on January 24, 2008 . As a work flow these are not hard and fast rules to impose on people. Instead it is intended to bring more uniformity and predictability to the life of a bug. If you have a good reason to break them, feel free. This is the process the triage team will follow.
This document applies only to 'conventional' bugs - i.e., it does not apply to special cases that happen to use the Bugzilla system, like package review requests.
Updated 17 March 2009 to reflect changes to the NEEDINFO representation.
Updated March 2010 to reflect No Frozen Rawhide Implementation.
States and Resolutions
NEW
When a reporter files a bug, the report automatically starts out in a NEW state. The triage team will be primarily looking at bugs in this state. From this state, the triage team will change the status to:
- NEW: but with Triaged keyword: The bug is well defined and triaged
- CLOSED: Duplicate, not a bug, not part of Fedora, etc.
- NEW but with needinfo flag: More information needed from reporter before being Triaged.
Needinfo
The needinfo flag is added by bug triagers or maintainers when adequate information is missing to move the bug towards resolution. If adequate information is provided, the triager will clear the flag, and set the bug to NEW with the Triaged keyword. If not, needinfo bugs are eligible for closure (changed to CLOSED INSUFFICIENT_DATA) by the triage team after all of the following have been met:
- Bug was originally placed in needinfo by a triager or package maintainer
- Requested information requested has not been provided
- Bug has been flagged needinfo for 30 continuous days
A stock message will be used by all triagers for bugs meeting the closure criteria. Stock bug triaging messages are found at BugZappers/StockBugzillaResponses.
Because needinfo is a flag and not an exclusive state, these bugs can also simultaneously be marked as NEW, ASSIGNED, etc, where appropriate.
Triaged
The Triaged keyword is added once the triage team believes that this is a complete actionable bug. It contains:
- the correct product
- the correct component
- enough information for the package maintainer to investigate the issue
- enough information to research with upstream or fix the bug
- applicable release blocker or tracker bugs
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
- AVC message for SELinux
See BugsAndFeatureRequests for more details.
ASSIGNED
The ASSIGNED state is to be used by component maintainers (and maintainer teams) in the way that is most useful to their particular workflow. For a single-maintainer component, the maintainer may wish to set all bugs to ASSIGNED or none to ASSIGNED, or use it to denote bugs s/he is actively working on, for instance. For components with a group of maintainers, the state could be used to indicate the bug has been assigned to one particular maintainer from the group. These are just suggestions; component maintainers are free to use this status in the manner they find most useful.
ON_DEV
This optional state is used to show that someone is working on fixing this bug. This is especially useful if there exists a team of maintainers for a package.
POST
- This state is primarily used by developers working on virtualization and the kernel.
- A bug is moved to the POST state (from ASSIGNED) when a patch has been attached to the bugzilla entry and the gate keeper is waiting for the patch to receive three ACKS. Therefore, POST means "a patch is ready, but not yet applied".
- After the patch is applied to the package the bug state changes to MODIFIED.
MODIFIED
When a maintainer has a fix for a bug checked into CVS the bug should be placed in the MODIFIED state. This is an indication that the fix is checked into CVS and has potentially been submitted to be built in a new package. Adding a link to package in koji is very helpful for adventuresome testers and the original bug reporter to verify the fix.
The use of MODIFIED for Rawhide bugs, or non-critical-path Branched bugs outside of freeze times, is optional; a maintainer may choose to use it to ask the reporters to test the fixed package to make sure the fix works before closing the bug, but can also go direct to CLOSED RAWHIDE (or CLOSED ERRATA for Branched bugs) on committing a fix, or change a MODIFIED bug to CLOSED if no reporter appears willing or able to confirm the fix.
ON_QA
A bug automatically transitions to this state when an updated package is submitted to bodhi for a particular bug and the package is in the testing repo. 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 bodhi and add a comment to the Bugzilla.
VERIFIED
The VERIFIED state indicates that a bug has a confirmed fix available in an updated package. A fix is considered confirmed due to user's comments in Bodhi or Bugzilla, or it may be confirmed by bug reporters and triagers through first-hand tests. The release of Fedora must match for both the bug report and the updated package. User intervention, such as workarounds or manually-applied patches, do not meet the requirements for this state, as they are not contained in a package.
VERIFIED is the final state that is manually set before the bug is automatically closed by Bodhi.
CLOSED
Once a bug has been fixed and included in a new package in rawhide or the updates repo it should be closed. For a stable or Branched release, the resolution ERRATA should be used. For Rawhide, the resolution RAWHIDE should be used.
The DEFERRED resolution is not intended for use by Fedora (it is used in the RHEL process).
For Rawhide, maintainers can choose to move to CLOSED RAWHIDE as soon as they commit a fix to CVS, if outside a freeze period; the MODIFIED process is optional.
- Bugs can be closed as DUPLICATE by a triager or 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 by triagers during the triage stage if it becomes clear they are not truly a bug in Fedora (e.g. the reporter's hardware is malfunctioning), or by the maintainer.
- The resolutions CANTFIX, WONTFIX, and WORKSFORME are for use by maintainers only, and are self-explanatory.
- The resolution CURRENTRELEASE is to be used in the case where a bug is reported before a release is made, and subsequently discovered to be fixed in the final release. For instance, a bug is reported against Fedora 42 while it is still in the pre-release stages, and remains open when the release is made; however, when the final Fedora 42 is made, the reporter re-tests and discovers the bug was actually fixed. In this case, the CURRENTRELEASE resolution is used.
- The resolution NEXTRELEASE is for use by maintainers only. It is used if a bug was filed for a given release, but will only be fixed for later releases - for instance, if a bug is filed in the current stable release, but the maintainer only thinks it safe or worthwhile to fix it in Rawhide and future releases, not the release on which it was reported.
- The resolution UPSTREAM can be used by maintainers to denote a bug that they expect to be eventually fixed by upstream development and naturally rolled back into Fedora as part of the update process. Ideally, a comment should be added with a link to the upstream bug report.
If so designated by the maintainer, Bodhi can automatically close a bug when the package moves from the updates-testing repo to the updates repo.
FAILS_QA, RELEASE_PENDING
The FAILS_QA and RELEASE_PENDING bug states are not used by Fedora (they are used in the RHEL process).
Priority and Severity
The severity field is used to indicate how severe the bug is, objectively speaking. It is initially set by the triager, and ultimate control rests with the assignee of the bug and/or the package maintainer(s). If the assignee and/or package maintainer(s) change the initial severity level chosen by the triager, the triage team may not then change the field further.
The priority field may be used, at their choice, by maintainers to keep track of the order in which they wish to address bugs in their package(s). This may be done with relation to the severity setting, or by any other method the maintainer chooses, at the maintainer's sole discretion. It may also be entirely ignored, if the maintainer in question does not wish to use it. No-one other than the maintainer or team responsible for a particular bug should change this setting at any point.
Reporters have no access to set the severity or priority fields. This is by design. The priority field exists solely for the convenience of the development team, and it is usually the case that only triagers and maintainers have a sufficient overview of all issues correctly to determine the severity of any particular bug.
Severity
The values for the severity field should be assigned with reference to the following guidance:
- Urgent: the bug makes whole system unusable (or it is a security bug, which is per definition urgent)
- High: the bug makes the program in question unusable, or a major packaging guideline violation (license problem, bundled library, etc)
- Medium: a real bug which makes program more difficult to use, at least part of the program is available; possibly workarounds are available
- Low: anything else - cosmetic issues, corner cases with unusual (non-default) configurations, etc.
For most packages, most issues are likely to be of medium severity. These are not hard and fast rules, and triagers (and maintainers) should use their best judgement in setting the severity field appropriately. There are obvious cases which require the exercise of judgement - for instance, a bug which affects more than just the program in which it occurs, but less than the 'whole system'.
See also
- A Bug's Life Cycle for definitions of other Bugzilla statuses and resolutions. Where that page comes into conflict with this one, in the case of Fedora and EPEL, this page takes precedence: in the case of Red Hat Enterprise Linux and other Red Hat products, that page takes precedence.