Arbeitsablauf für den Bug-Status

Dieses Dokument beschreibt bewährte Vorgehensweisen für die Festlegung des Bugzilla-Status für Fehler und Funktionsanfragen. Verwenden Sie für Änderungsvorschlags-Tracker den in der Änderungsrichtlinie beschriebenen Bugzilla-Status.

Status

Die folgende Abbildung zeigt ein allgemeines Ablaufdiagramm für Fehler im typischen Fall. Der Ablauf ist bidirektional: Ein Fehler kann in einen vorherigen Zustand zurückfallen, wenn beispielsweise eine vorgeschlagene Korrektur unvollständig ist.

Die folgende Tabelle fasst die Status zusammen. Weitere Details, einschließlich zusätzlicher Schlüsselwörter, Kennzeichnungen und Lösungen, finden Sie in den folgenden Abschnitten.

Tabelle 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.

Lösungen

Die folgende Tabelle beschreibt die Lösungen, die für den Status CLOSED gesetzt werden können.

Tabelle 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.

Priorität und Schweregrad

Schweregrad

Das Feld Severity („Schweregrad“) dient zur Angabe der Wichtigkeit des Fehlers. Die Werte für das Feld Severity sollten gemäß den folgenden Richtlinien vergeben werden:

Urgent: Der Fehler macht das gesamte System unbrauchbar (oder es handelt sich um einen Sicherheitsfehler, der per Definition dringend ist)
High: Der Fehler macht das betreffende Programm unbrauchbar oder stellt einen schwerwiegenden Verstoß gegen die Paketbaurichtlinien dar (Lizenzproblem, gebündelte Bibliothek usw.)
Medium: Ein echter Fehler, der die Nutzung des Programms erschwert; zumindest ein Teil des Programms ist jedoch nutzbar; möglicherweise gibt es Behelfslösungen
Low: Alles andere – kosmetische Probleme, Sonderfälle mit ungewöhnlichen (nicht standardmäßigen) Konfigurationen usw.

Der Schweregrad Urgent sollte in der Regel nicht für hardwarespezifische Fehler verwendet werden: Ein Fehler, der die gesamte Distribution betrifft, aber auf einen bestimmten Hardwaretyp beschränkt ist, sollte üblicherweise auf High gesetzt werden. Wenn beispielsweise ein Fehler die korrekte Funktion von X.org auf einem bestimmten Grafikchipsatz verhindert, verwenden Sie den Schweregrad High und nicht Urgent.

Bei den meisten Paketen dürften die meisten Probleme den Schweregrad Medium haben. Dies sind jedoch keine festen Regeln. Verwenden Sie Ihr bestes Urteilsvermögen, um das Feld für den Schweregrad angemessen festzulegen. Es gibt offensichtliche Fälle, die eine Beurteilung erfordern – beispielsweise ein Fehler, der zwar mehr als nur das Programm, in dem er auftritt, aber weniger als das „gesamte System“ betrifft.

Priorität

Das Feld Priority kann von den Paketbetreuern nach Belieben verwendet werden, um die Reihenfolge der Fehlerbehebung in ihren Paketen festzulegen. Dies kann in Bezug auf den Schweregrad oder nach einer anderen vom Paketbetreuer gewählten Methode erfolgen. Es kann auch vollständig ignoriert werden, wenn der betreffende Paketbetreuer es nicht verwenden möchte. Niemand außer dem Paketbetreuer oder dem für einen bestimmten Fehler verantwortlichen Team sollte diese Einstellung ändern.

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