Bugzilla verwenden

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

Fedora verwendet Red Hat Bugzilla zur Fehlerverfolgung. Diese Seite und die anderen Seiten unter der Überschrift »Bugs« auf der linken Seite bieten einige Tipps und Anleitungen.

Permissions

Alle Benutzer, auch anonyme (d.h. nicht angemeldete) Benutzer, können Fehler betrachten. (Beachten Sie, dass einige Fehler oder Kommentare als »privat« gekennzeichnet oder auf bestimmte Gruppen beschränkt sein können. Dies ist in Fedora selten und dient in der Regel dem Schutz vertraulicher Informationen, die in Anhängen oder Protokollausschnitten enthalten sein können.)

Jeder angemeldete Benutzer kann einen Fehlerbericht erstellen oder einen Kommentar zu einem vorhandenen Fehlerbericht hinzufügen.

Der Melder oder derjenige, dem der Fehlerbericht zugewiesen ist, kann jedes Feld in seinem eigenen Fehlerbericht ändern.

Erstellung eines Benutzerkontos

Sie benötigen ein Bugzilla-Konto, um Fehler zu melden und mit ihnen zu interagieren. Sobald Sie ein Konto bei Bugzilla erstellt haben, können Sie sich auch über Ihr Fedora-Konto anmelden. Um sich mit Ihrem FAS-Konto bei Bugzilla anzumelden, müssen Sie entweder für FAS und Bugzilla dieselbe E-Mail-Adresse verwenden oder, falls diese unterschiedlich sind, die Bugzilla-E-Mail-Adresse explizit in Ihrem FAS-Profil hinterlegen.

Automatische Änderungen

Bugzilla erstellt automatisch Links zu Fehlerberichten oder Kommentaren, die dem Muster „bug xxxx“ oder „comment xxxx“ folgen.

Fehlerberichte, die als Duplikat gekennzeichnet sind, erhalten automatisch einen Kommentar, der auf den anderen Fehlerbericht verweist. Der andere Fehlerbericht erhält automatisch einen Kommentar, der darauf hinweist, dass ein anderer Fehler als Duplikat gekennzeichnet wurde.

Bodhi – das Fedora-Aktualisierungssystem – kommentiert und ändert den Status der zugehörigen Fehlerberichte automatisch, während Aktualisierungen durch das System laufen.

Status und Auflösung

Bugzilla verwendet Felder namens »Status« und »Resolution« (Auflösung), um den Status eines Fehlerberichts oder einer Funktionsanfrage zu verfolgen.

Status

Die nachfolgende Tabelle fasst die Status zusammen.

Table 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

In der folgenden Tabelle werden die Lösungen beschrieben, die für den Status CLOSED (geschlossen) gelten können.

Table 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 ›