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.

fedora bug lifecycle

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.

Unresolved include directive in modules/ROOT/pages/bug_status.adoc - include::program_management::partial$bz_status.adoc[]

Lösungen

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

Unresolved include directive in modules/ROOT/pages/bug_status.adoc - include::program_management::partial$bz_resolution.adoc[]

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.