Wie werden Bugs kategorisiert und wie sieht der Lebenszyklus eines Bugs aus?

Wie werden Fehler in Ubuntu kategorisiert und wie sieht der Lebenszyklus eines Fehlers aus?

Außerdem: "Was bedeutet der 'Status' jedes Fehlers und wie wird er ermittelt?"

Alle Fehler in Ubuntu haben Lebenszyklen. Außerdem haben sie jeweils einen "Status", mit dessen Hilfe der Lebenszyklus erklärt werden kann. In Ubuntu sind für jeden Fehler im Verlauf seines Lebenszyklus verschiedene Status festgelegt.

Obwohl dies alles in der Triage-Anleitung außerordentlich detailliert dokumentiert ist , werde ich (im Moment habe ich nicht viel Zeit, um diesen Prozess in Textform zu schreiben, aber ich werde es später veröffentlichen) die "Flussdiagramme", die von bereitgestellt werden das Bug Squad dafür ( klicken Sie hier für die Quelle der Flussdiagramme ). Jeder Status (in der Zwischenzeit) kann in der Bugs / Status BugSquad-Dokumentation erklärt werden , aber ich habe sie auch hier dokumentiert.

(Beachten Sie, dass die folgenden Informationen in der Dokumentation im Wiki möglicherweise nicht mehr aktuell sind. Die aktuellsten Informationen finden Sie im Wiki.)

Das Folgende ist eine Beschreibung jeder Statusanzeige eines Fehlers:

• Neu:
  • Fehler werden mit diesem Status gemeldet
  • Ihnen fehlen manchmal Informationen und
  • Alle von ihnen sollten nicht ausprobiert werden
• Unvollständig:
  • Wenn Sie dem Reporter Fragen stellen müssen, setzen Sie den Fehler auf Unvollständig
  • Bitten Sie den Absender, die erforderlichen Informationen in einem Kommentar anzugeben, und stellen Sie sicher, dass Sie sich für den Fehlerbericht anmelden, damit Sie per E-Mail über Updates des Fehlers informiert werden.
  • Einige Bugs werden vom Einsender nie beantwortet (auch "Originalposter" oder "OP" genannt). Diese Fehler werden von Launchpad nach 60 Tagen automatisch gelöscht, gerechnet ab dem Tag, an dem sie als unvollständig eingestuft wurden. Es besteht keine Notwendigkeit, auf sie zu reagieren (und tatsächlich wird der Ablaufzeitraum neu gestartet, wenn der Fehler geändert wird). Beachten Sie, dass dies für das Ubuntu-Projekt gilt (dh für die Bug-Tasks, deren Name "(Ubuntu)" enthält). Bei anderen Projekten ist möglicherweise das automatische Ablaufdatum für unvollständige Fehler festgelegt.
  • Wenn jemand, einschließlich Sie, Kommentare zu dem Fehler abgibt, wird die 60-Tage-Ablaufuhr zurückgesetzt.
• Meinung:
  • Der Status "Meinung" bedeutet, dass es zu einem bestimmten Fehler Meinungsverschiedenheiten gibt und die Diskussion fortgesetzt werden kann. Die Projekt- oder Paketbetreuer müssen jedoch zu einer anderen Arbeit übergehen und das Problem als geschlossen betrachten. Die Idee ist, dass Fehler als geschlossen markiert werden können, damit Entwickler keine Zeit damit verschwenden, aber die Diskussion kann noch andauern.
  • Diese Statusmeinung wird als Experiment betrachtet und genau überwacht.
• Ungültig:
  • Dieser Status sollte verwendet werden, wenn der Fehlerbericht keine ausreichenden Informationen enthält, um festzustellen, ob es sich um einen Fehler handelt oder nicht, auch wenn er für den Reporter behoben wurde
  • Dies sollte auch verwendet werden, wenn das gemeldete Problem kein Fehler ist, sondern beispielsweise ein Benutzerfehler
  • Es sollte konservativ verwendet werden, da Fehler, die als ungültig markiert sind, in den Standardsuchen nicht mehr angezeigt werden
  • Überprüfen Sie einen Fehler dreimal, bevor Sie ihn ungültig machen
• Abgelaufen:
  • Dieser Status ähnelt dem Status "Ungültig", ist jedoch speziell für Fehler gedacht, die zu lange unvollständig waren. (Siehe oben.)
  • Dieser Status kann nur mithilfe von launchpadlib oder der E-Mail-Schnittstelle festgelegt werden.
  • Wie ungültige Fehler werden abgelaufene Fehler in den Standardsuchen nicht angezeigt.
• Bestätigt :
  • Ein anderer Reporter hat den gleichen Fehler festgestellt. Dies kann in Form eines doppelten Fehlers oder eines Fehlerkommentars auftreten
  • Bestätigte Fehler müssen von einer anderen Person als dem ursprünglichen Reporter bestätigt werden
  • Dies hilft sicherzustellen, dass der Fehler generell auf Ubuntu zutrifft und kein Problem mit dem System des Reporters darstellt.
  • Bitte bestätigen Sie nicht Ihre eigenen Fehler!
• Triaged:
  • Ein Mitglied von UbuntuBugControl ist der Ansicht, dass der Bericht einen echten Fehler so ausführlich beschreibt, dass ein Entwickler mit der Arbeit an einem Fix beginnen kann. (siehe auch Tipp unten)
  • Verwenden Sie diese Option, wenn Sie sicher sind, dass sie von einem Entwickler gelesen werden sollte und über genügend Informationen verfügt
  • Obwohl dies nicht erforderlich ist, wird der Ubuntu-Task-Status eines Fehlers vor dem Auftreten von Upstream-Weiterleitungen überprüft
  • Bei Bugs über Linux bedeutet Triaged, dass der Bug mit dem Upstream-Mainline-Kernel getestet wurde
• In Bearbeitung:
  • Wenn Sie daran arbeiten, einen Fehler zu beheben, setzen Sie ihn auf In Bearbeitung, damit die Leute wissen, was los ist
  • In Bearbeitung Fehler sollten der Person zugewiesen werden, die an ihnen arbeitet
• Fix Committed:
  • Ubuntu-Bug-Task: Die Änderungen stehen noch aus und werden bald hochgeladen (wie PENDINGUPLOAD in Bugzilla)
  • "Fix Committed" wird auch verwendet, wenn ein aktualisiertes Paket in einem vorgeschlagenen Repository vorhanden ist, dh wenn es nur schwer vorgeschlagen wird
  • Fix Committed wird nicht verwendet, wenn ein Patch an einen Fehler angehängt ist
  • Upstream-Bug-Task: Der Fix befindet sich in CVS / SVN / bzr oder wurde an einer bestimmten Stelle ausgeführt
• Fix freigegeben:
  • Ubuntu-Bug-Aufgabe: Ein Fix wurde in ein offizielles Ubuntu-Repository hochgeladen
  • NB Dies beinhaltet nicht-vorgeschlagen, dh hardy-vorgeschlagen
  • Bitte zögern Sie nicht, ein Changelog als Kommentar hinzuzufügen, damit die Leute wissen, in welcher Paketversion ein Fehler behoben wurde
  • Wenn ein Fehler in der aktuellen Entwicklungsversion behoben ist, handelt es sich um "Fix Released". Wenn der Fehler auch in einer stabilen Version behoben werden muss, verwenden Sie den Link "Target to release", um ihn für diese Version zu nominieren.
  • Upstream-Bug-Task: Ein Release-Tarball wurde angekündigt und ist öffentlich verfügbar
• Wird nicht behoben:
  • Dieser Status wird manchmal verwendet, wenn die Fehlerbehebung zu kontrovers ist
  • Es wird am häufigsten für Fehler mit einem Versionsziel verwendet, die in dieser bestimmten Version nicht behoben werden, aber möglicherweise später behoben werden
  • Es kann auch für Feature-Anforderungen verwendet werden, die die Entwickler nicht implementieren möchten

(Die Formatierung weicht geringfügig vom Wiki ab, da die Formatierung hier eingeschränkter ist.)

Verwandte Fragen und Antworten:
Wichtigkeitswert: Wie werden die Wichtigkeitswerte von Ubuntu-Bugs bestimmt?