Using Bugzilla

Ben Cotton Versi F36 onwards Last review: 2024-01-18

Fedora uses Red Hat Bugzilla for bug tracking. This page and the other pages under the "Bugs" header on the left offer some tips and guidance.

Permissions

Any user, including "anonymous" (i.e. not logged in) users can view bugs. (Note that some bugs or comments may be marked "private" or restricted to specific groups. This is rare in Fedora and is generally to protect sensitive information that might be in an attachment or log snippet.)

Any logged-in user can create a bug report or add a comment to an existing bug.

The reporter or assignee of a bug can modify any field in their own bug.

Creating an account

You must have a Bugzilla account to file bugs and interact with them. Once you have created an account on Bugzilla, you can also login using your Fedora account. To use your FAS account to login to Bugzilla, you need to either use the same e-mail address on FAS and on Bugzilla, or if they differ, you can set the Bugzilla e-mail address in your FAS profile explicitly.

Automatic changes

Bugzilla will automatically create links to bug reports or comments that follow the pattern "bug xxxx" or "comment xxxx".

Bugs marked as duplicate will automatically get a comment referring to the other bug report. The other bug report will automatically get a comment indicating that another bug has been marked as a duplicate of it.

Bodhi — the Fedora updates system — will automatically comment and change the status of associated bugs as updates move through the system.

Status and resolution

Bugzilla uses fields called "Status" and "Resolution" to track the state of a bug report or feature request.

Status

The table below summarizes the statuses.

Tabel 1. Bugzilla statuses
Status	Meaning
NEW	The default state. Generally indicates bug has not been actively investigated by the assignee.
ASSIGNED	Can be used by maintainers to indicate that the bug has been vetted and is assigned for work.
ON_DEV	Can be used by maintainers to indicate that work is actively in progress. This is especially useful if there exists a team of maintainers for a package.
POST	Indicates a fix is ready, but not applied. This is often used when a pull request is open upstream.
MODIFIED	Indicates a fix has been built in an update. Bodhi will set this status automatically when an update is created if the bug is associated with the update.
ON_QA	Indicates an update with a fix is in the testing repo. Bodhi will set this status automatically when an update reaches updates-testing if the bug is associated with the update.
VERIFIED	Indicates a bug has a confirmed fix in an update.
RELEASE_PENDING	(Generally unused in Fedora. Used for Red Hat Enterprise Linux workflows.)
CLOSED	Indicates the bug has been fixed or will not be fixed. The CLOSED status has different resolutions to indicate why the bug was closed. Bodhi will set this status automatically when an update reaches the updates repo if the bug is associated with the update.

Resolution

The table below describes the resolutions that can apply to the CLOSED status.

Tabel 2. Bugzilla resolutions
Resolution	Meaning
CANTFIX	Used by maintainers to indicate a bug that cannot be fixed.
CURRENTRELEASE	Indicates a bug reported in Branched prior to release and the fix is fixed for the final release.
DEFERRED	(Generally unused in Fedora. Used for Red Hat Enterprise Linux workflows.)
DUPLICATE	Indicates a bug is a duplicate of another.
EOL	Indicates a bug that was filed against a version that has reached End of Life.
ERRATA	Indicates a bug is fixed in a stable release.
FAILS_QA	(Generally unused in Fedora. Used for Red Hat Enterprise Linux workflows.)
INSUFFICIENT_DATA	Indicates that the bug reporter is unwilling or unable to provide sufficient information to diagnose or fix the bug.
NEXTRELEASE	Used by maintainers to indicate a bug that will only be fixed for later releases, not on the release reported.
NOTABUG	Indicates that the report is not a bug (e.g. is a hardware failure or a support question).
RAWHIDE	Indicates a bug is fixed in a Rawhide update.
RELEASE_PENDING	(Generally unused in Fedora. Used for Red Hat Enterprise Linux workflows.)
UPSTREAM	Used by maintainers to indicate that a bug is expected to be fixed upstream and naturally rolled into Fedora Linux in a subsequent update.
WONTFIX	Used by maintainers to indicate a bug that will not be fixed.
WORKSFORME	Used by maintainers to indicate a bug that cannot be reproduced.

Want to help? Learn how to contribute to Fedora Docs ›