[ English | Deutsch | français | русский | English (United Kingdom) | Indonesia | 한국어 (대한민국) ]

OpenStack-Ansible Bug-Behandlung

Fehlerberichterstattung

Fehler sollten im OpenStack-Ansible Launchpad-Projekt abgelegt werden.

Wenn Sie einen Fehler senden oder an einem Fehler arbeiten, stellen Sie bitte sicher, dass die folgenden Kriterien erfüllt sind:

  • In der Beschreibung wird das ursprüngliche Problem oder die Ursache des Problems eindeutig angegeben oder beschrieben.

  • Die Beschreibung gibt klar das erwartete Ergebnis der Benutzeraktion an.

  • Fügen Sie historische Informationen zur Identifizierung des Problems hinzu.

  • Alle relevanten Protokolle oder Benutzerkonfigurationen sind enthalten, entweder direkt oder über eine Pastebin.

  • Wenn das Problem ein Fehler ist, der in einem anderen Zweig als Master behoben werden muss, beachten Sie bitte die zugehörige Verzweigung innerhalb des Launchpad-Problems.

  • Die bereitgestellten Informationen sollten vollständig eigenständig sein. Externer Zugriff auf Web-Services/Websites sollte nicht benötigt werden.

  • Schritte, um das Problem nach Möglichkeit zu reproduzieren.

Fehler Tags

Wenn das gemeldete Problem in einem Zweig neben dem Master behoben werden muss, fügen Sie ein ‚<release> -backport-potential‘ hinzu (z.B. liberty-backport-potential). Es gibt vordefinierte Tags, die automatisch vervollständigt werden.

Status

Bitte lassen Sie den Status eines Problems alleine, bis jemand es bestätigt oder ein Mitglied des Bugs-Teams es ausprobiert. Während Sie darauf warten, dass das Problem bestätigt oder bestätigt wird, sollte der Status als New beibehalten werden.

Bedeutung

Sollte nur angefasst werden, wenn es sich um ein Blocker/Gating-Problem handelt. Wenn dies der Fall ist, stellen Sie bitte High ein und verwenden Sie nur Critical, wenn Sie einen Fehler gefunden haben, der ganze Infrastrukturen zerstören kann. Sobald die Wichtigkeit geändert wurde, sollte der Status von jemand anderem als dem Ersteller des Bugs auf Triaged geändert werden.

Der Triage-Vorgang wird nachfolgend erläutert.

Fehlersuche

Was ist eine Fehlersuche?

„Bug Triage ist ein Prozess, bei dem Tracker-Probleme überprüft und priorisiert werden. Triage sollte dazu beitragen, dass wir alle gemeldeten Probleme - Bugs sowie Verbesserungen und Feature-Anfragen - angemessen verwalten.“ (Quelle: Moodle Bug Triage)

Berichtete Fehler müssen bestätigt und priorisiert werden und sicherstellen, dass sie nicht veraltet sind. Wenn Sie an der Stabilität von OpenStack interessiert sind, aber die Rollen und Playbooks, die im OpenStack-Ansible-Projekt verwendet werden, nicht aktiv entwickeln möchten, sollten Sie einen Beitrag im Bereich der Fehlersuche leisten.

Bitte beziehen Sie sich auf den Project Team Guide bugs reference_ für Informationen über Fehlerstatus/Wichtigkeit und den Lebenszyklus eines Fehlers.

Aufgaben für Fehlersuche-Meetings

Wenn die Fehlerbeschreibung unvollständig ist oder der Bericht nicht über die erforderlichen Informationen verfügt, um das Problem zu reproduzieren, bitten Sie den Reporter, fehlende Informationen anzugeben und den Fehlerstatus auf Unvollständig festzulegen.

Wenn der Fehlerbericht genügend Informationen enthält und Sie ihn reproduzieren können (oder er als gültig erscheint), sollten Sie seinen Status auf Confirmed setzen.

Wenn der Fehler Auswirkungen auf die Sicherheit hat, setzen Sie das Sicherheitszeichen (unter „Dieser Bericht ist öffentlich“ oben rechts)

Wenn der Fehler einen bestimmten Bereich betrifft, der von einem offiziellen Tag abgedeckt wird, sollten Sie das Tag festlegen. Wenn der Fehler zum Beispiel leicht zu lösen ist, fügen Sie das Tag low-hanging-fruit hinzu.

Das Bug-Triage-Treffen ist wahrscheinlich eine gute Zeit für Leute mit Bug-Supervisor-Rechten, Bugs auch nach Wichtigkeit zu priorisieren (zusätzlich zur Klassifizierung nach Status).

Bug-Skimming-Pflicht

Um Bugs zu lösen, kann eine Person des Bug-Teams Bug Skimming Duty sein.

Q

Was ist die Aufgabe des Bug Skimming Duty?

A

Bug Skimming Duty reduziert den Aufwand, den andere Entwickler für die Ursachenanalyse (und spätere Behebung) von Fehlerberichten aufwenden müssen. Schließen Sie dazu die offensichtlich ungültigen Fehlerberichte, bestätigen Sie die offensichtlich gültigen Fehlerberichte, stellen Sie Fragen, wenn die Dinge unklar sind.

Q

Muss ich beweisen, dass ein Fehlerbericht gültig/ungültig ist, bevor ich ihn auf Confirmed/Invalid setzen kann?

A

Nein. Manchmal ist es nicht einmal möglich, weil Sie nicht über die Ressourcen verfügen. Wenn Sie sich den Code und die Tests ansehen, können Sie häufig eine fundierte Vermutung abgeben. Wenn Sie Ihre Quellen in einem Kommentar zitieren, hilft das der Diskussion.

Q

Was ist der beste Status, um einen Fehlerbericht zu schließen, wenn das Problem nicht reproduziert werden kann?

A

Definitiv Ungültig. Der Status Incomplete ist ein offener Status und bedeutet, dass mehr Informationen benötigt werden.

Q

Wie gehe ich mit offenen Fehlerberichten um, die zu lange unvollständig sind?

A

Wenn es länger als 30 Tage in diesem Zustand ist und keine Antworten auf die offenen Fragen gegeben werden, schließen Sie es mit Won’t Fix.

Q

Wie gehe ich mit Abhängigkeiten zu anderen Fehlern oder TBD-Funktionen in anderen Projekten um? Zum Beispiel kann ich einen Fehler in OpenStack-Ansible beheben, aber ich brauche, dass eine Funktion in Compute (Nova) zuvor implementiert wird.

A

Hinterlassen Sie einen Kommentar im OpenStack-Ansible-Fehlerbericht, der diese Abhängigkeit erklärt und einen Link zum Blueprint- oder Fehlerbericht des anderen Projekts, auf das Sie angewiesen sind.

Q

Muss ich Fehlerberichte, die neu sind und einen Beauftragten haben, erneut prüfen?

A

Normalerweise nicht. Dieser Fehlerbericht weist jedoch einen inkonsistenten Status auf. Wenn ein Fehlerbericht einen Bearbeiter hat, sollte dieser in Bearbeitung sein und eine Wichtigkeits-Einstellung haben.

Bug Checking Pflicht wöchentliche Checkliste

  • Priorisieren oder repriorisieren Sie OpenStack-Ansible confirmed bugs.

  • Verschieben Sie uralte wishlist bugs zu Opinion/Wishlist, um Unordnung zu entfernen. Sie können die folgende Nachricht verwenden:

    Dieser Wunschliste-Bug wurde ein Jahr lang ohne Aktivität geöffnet. Ich ziehe das auf „Opinion/Wishlist“. Dies ist eine leicht erhältliche Warteschlange für ältere Anfragen. Dieser Fehler kann wieder geöffnet werden (zurück auf „New“), wenn sich jemand dazu entschließt, daran zu arbeiten.

  • Verschieben Sie Fehler, die nicht reproduziert werden können, in einen ungültigen Zustand, wenn sie länger als einen Monat nicht geändert wurden.

  • Senden Sie eine E-Mail an die openstack-discuss-Liste mit der Liste der Fehler, die während der Woche ausgewählt werden sollen. Ein neuer Fehler, der mit Critical oder High markiert ist, muss vorrangig behandelt werden.