From Mageia wiki
Jump to: navigation, search


Drakconf multiflag.png
Andere Sprachen
Deutsch ; English ; Français ;
Diese Seite wurde im März 2019 von wiki.mageia.org/de/ übernommen und erweitert. Für die ursprüngliche/n Seite/Autoren siehe hier. Hierbei handelt es sich um eine Übersetzung aus dem englischen.


Gehe zum Portal der Fehlertruppe

Einleitung

Dieser Artikel beschäftigt sich mit dem Prozess der Behandlung von Fehlerberichten für Mageia. Das Ziel dieses Dokuments ist es, die Verantwortlichkeiten aller betroffenen Teile klar zu machen (Berichterstatter, Mitglieder der Fehlertruppe und Paketbetreuer), und um alle unvorhersehbaren Möglichkeiten abzudecken, so dass immer klar sein sollte welche Aktion von wem eingeleitet werden soll um einen Fehler zu beheben.

Definition

Ein Fehler ist als der Fall definiert, in dem eine Komponente einer Mageia Linux Distribution (oder andere Komponenten die von Mageia Bugzilla abgedeckt werden), nicht die zu erwartete(n) Funktion(en) erfüllt.

Prozess

Fehler können von jedem Anwender der Distribution an Mageia gemeldet werden. Wir beabsichtigen alle an Mageia gemeldete Fehler zu behandeln. Dies bedeutet nicht notwendigerweise dass alle Fehler in der Weise gelöst werden, wie es der Berichterstatter erwartet; obwohl wir uns darum bemühen wo immer möglich, ist es manchmal nicht möglich. Wir versuchen, wo immer möglich, ungültige oder falsch adressierte Fehler richtig zu behandeln und gültige zu lösen.

Die bedeutet dass legitime Fehlermeldungen in unterstützten Paketen so schnell wir möglich behoben werden müssen. Dort wo Fehler nicht behoben werden können ist eine vollständige Erklärung der Umstände nötig. Eines dieser beiden Ereignisse bildet die Lösung. Dort wo Fehlermeldungen doppelt, ungültig, ausserhalb des Aufgabenbereichs eines Fehlerlösungssystems liegen oder als unmöglich reproduzierbar auftreten, muss dieser Fehler als RESOLVED, mit dem entsprechenden Status markiert werden und entweder vom Paketbetreuer oder einem Mitglied der Fehlertruppe eine vollständige Erklärung angefügt werden. Diese Ergebnisse bilden ebenfalls eine Lösung. Kein anderes Ergebnis kann als Lösung angesehen werden.

Berichten

Fehlerberichte werden mittels Bugzilla abgewickelt. Vom Berichterstatter muss die Distribution und das Produkt ausgewählt werden. Ein Fehlerbericht sollte eine vollständige Beschreibung des Problems enthalten, und wenn möglich, eine detaillierte Beschreibung der Schritte die nötig sind um das Problem nachzuvollziehen. Alle relevanten Informationen über die Umgebung, die nötig sind, um das Problem nachvollziehen zu können - spezielle Elemente der Hardware, spezielle Softwarepakete oder spezielle Konfigurationseinstellungen - müssen ebenso enthalten sein. Anregungen zu einer Fehlerbehebung, inklusive Patches sind immer willkommen, aber keine Bedingung.

Auswahl

Alle Fehler sollten zu Beginn in den Zuständigkeitsbereich der Fehlertruppe fallen. Während der Auswahl hat die Fehlertruppe zwei wichtige Pflichten. Zuerst muss die Fehlertruppe entscheiden, ob ein berichteter Fehler/Problem eine Aktion seitens des Paketbetreuers erfordert oder nicht.

Dinge die keine Aktion vom Paketbetreuer benötigen

Die nachfolgend aufgeführten Fälle benötigen keine Aktion durch den Paketbetreuer. Benötigt ein auftretendes Problem keine Aktion durch die Paketbetreuer, so obliegt es der Fehlertruppe diese Fälle zu lösen.

  • Der Fehler ist ein //Duplikat// eines bestehenden Berichts. Dies bedeutet dass das gleiche Problem, zum gleichen Produkt in der gleichen Version, schon einmal berichtet wurde. Berichte über das gleiche Problem in einer //anderen Version// sind nicht als Duplikat zu betrachten. Mitglieder der Fehlertruppe sollten doppelte Fehlermeldungen auf den Status RESOLVED DUPLICATE setzen. Dies bezeichnet die Lösung dieses Falles.
  • Der gemeldete Fehler stellt keinen Fehler im Sinne der oben dargestellten Definitionen dar. Dies ist der Fall wenn z.B. der Fehlerbericht das hinzufügen einer neuen zusätzlichen Eigenschaft als Teil der Software anfordert, die nicht vom Mageia Entwicklerteam unterstützt wird, oder wenn ein Fehler die Folge eines Fehlers auf Seiten des Anwenders ist. Mitglieder der Fehlertruppe sollten bei Fehlermeldung die den Definitionen nicht entsprechen, den Status entweder auf RESOLVED INVALID oder auf RESOLVED WONTFIX setzen, außer im Falle einer legitimen Erweiterungsanforderung (welches weiterer unten in einem eigenen Abschnitt behandelt wird). Dies bildet eine Lösung in dieser Angelegenheit.
  • Die Fehlermeldung ist kein Duplikat und fällt auch in die Definition eines Fehlers, würde aber besser weiter oben in der Entwicklungskette (upstream) behandelt werden. Einige Dinge können auf Ebene der Paket-Distribution nicht vernünftig gelöst werden. Solche Dinge enthalten z.B. fundamentale Fehler im Code einer Anwendung. In diesem Fall empfehlen die Mitglieder der Fehlertruppe dem Berichterstatter den Fehler an die entsprechende Ebene der Entwicklerkette, mittels der dort am gängigsten empfohlenen Methode zur Fehlermeldung, für dieses Projekt zu melden - spricht: direkt beim Entwickler der Software/des Projekts (so ist es z.B. empfehlenswert den Fehler direkt an GNOME Bugzilla zu melden, wenn dies ein Fehler ist, der besser vom GNOME-Entwicklerteam behandelt werden sollte).
    Ist dies geschehen sollte die URL des Upstream gemeldeten Bugs in die Kopfzeile des Bugreports. Der Report sollte als offen markiert bleiben und als Schlüsselwort UPSTREAM hinzugefügt werden. Der bei Mageia gemeldete Fehler sollte nicht als RESOLVED markiert werden, bis eine Eintscheidung getroffen wurde (entweder als FIXED (behoben) oder als WONTFIX/OLD).

Fehler die eine Aktion durch den Paketbetreuer benötigen

Fehler die nicht in die oben genannte Kategorie fallen - dass sind Probleme auf die die Definition eines Fehlers zutreffen, die zuvor noch nicht gemeldet wurden, die nachvollzogen werden können und vernünftig auf der Ebene der Distributions-Pakete gelöst werden können - dies sind Fehler die ein Eingreifen der Paketbetreuer erfordern. In diesen Fällen liegt es in der Verantwortlichkeit der Fehlertruppe sicherzustellen, dass alle relevanten Informationen (wie oben im Absatz Berichten ausgeführt) vom Berichterstatter zur Verfügung gestellt werden, und die Felder Priority und Severity entsprechend gesetzt sind, sowie sicher zu stellen ist, dass der richtige Betreuer das Paket zugewiesen bekommt.
Die kann auch bei Bugreports zutreffen, welche als UPSTREAM markiert sind.

Mitglieder der Fehlertruppe sollten zugewiesene Fehler nicht an Paketbetreuer abgeben, bevor nicht sichergestellt ist, dass alle benötigten Informationen vorhanden sind.

Sind im anfänglichen Fehlerbericht alle benötigten Informationen enthalten, kann der Fehlerbericht ganz einfach dem entsprechenden Paketbetreuer zugewiesen werden. An dieser Stelle geht die Verantwortung für die Fehlerbehandlung an den Betreuer über.

Sind im anfänglichen Bericht nicht alle Informationen enthalten, sollten die Mitglieder der Fehlertruppe das Schlüsselwort NEEDINFO setzen und einen Kommentar anhängen in dem der Berichterstatter dieses Fehlers informiert wird welche zusätzlichen Informationen genau benötigt werden, sowie weitere Beschreibungen zum Problem oder einen Link zu einer Beschreibung einfügen, um die nötigten Schritte zu erklären damit man die benötigten Informationen erhält. Solange dieser Schritt nicht abgeschlossen ist, bleibt dieser Fehler in der Verantwortung der Fehlertruppe. Wurde eine solche Aktion ausgeführt liegt der weitere Verlauf der Behandlung in der Verantwortung des Berichterstatters, bis dieser die zusätzlichen Informationen zur Verfügung stellt. Wenn solche Informationen nicht innerhalb eines annehmbaren Zeitrahmens eintreffen oder der Berichterstatter mit nicht verwertbaren Informationen antwortet, muss der Paketbetreuer keine maßnahmen Tätigen und sollte von der Fehlertruppe entsprechend behandelt werden.

Die Fehlertruppe muss für jeden Fehler auch die Felder Priority und Severity entsprechend setzen. Die Betreuer verwenden diese Felder um den Arbeitsfluss zu priorisieren, so dass deren Genauigkeit wichtig ist.

  • Das Feld Priority reflektiert wie wichtig es ist diesen Fehler zu beheben; d.h. dieses Feld ist davon abhängig wie wichtig der Fehler im Kontext der Distribution als ganzes ist.
  • Das Feld Severity reflektiert wie gravierend der Fehler innerhalb des Kontextes des Pakets ist.

So kann ein kritischer Fehler in einem Paket, das selten verwendet wird, einen hohen Schweregrad aber eine geringe Priorität besitzen, und ein geringfügiger Fehler in einem weit verbreiteten Paket einen geringfügigeren Schweregrad aber eine hohe Priorität, aber dafür auch die Priorität release_blocker.

Prioritätswerte

  • Die Priorität release_blocker ist hauptsächlich für Fehler, die den Stabilisierungs-Schnappschuss oder Veröffentlichungskandidaten (RC) betreffen relevant (kein Fehler hat die Priorität release_blocker wenn eine bereits veröffentlichte Version der Distribution davon betroffen ist) und sollte nur für Probleme verwendet werden, die hinlänglich kritisch sind um die Qualität einer Version zu gefährden, wenn diese ohne den behobenen Fehler veröffentlicht wird.
  • Die Priorität high sollte für Fehler verwendet werden, wenn die Fehler hinlänglich kritisch sind und deren Behebung eine höhere Priorität gegenüber anderen Fehlern besitzt, aber nicht so hoch sind wie jene für release_blocker.
  • Die Priorität low sollte für Fehler verwendet werden die hinlänglich trivial und/oder nur sehr geringe Auswirkungen bei der Benutzung haben, so dass das Beheben anderer Fehler vorgezogen werden kann.
  • Die Priorität normal sollte für alle anderen Fehler verwendet werden.

Werte der Schweregrade

  • Der Schweregrad critical sollte für Fehler verwendet werden, wenn ein Paket im wesentlichen unbenutzbar wird (z.B., Abstürze die einen Großteil der Anwender dieses Pakets betreffen, oder wenn es unmöglich ist das Paket zu installieren oder auszuführen).
  • Der Schweregrad major sollte für Fehler verwendet werden, die eine signifikante Fähigkeit eines Pakets betreffen, so dass ein Paket nicht mehr verwendet werden kann oder instabil wird.
  • Der Schweregrad minor sollte für Fehler verwendet werden, wenn es nur einige begrenzte Auswirkung auf die Anwendbarkeit des Pakets gibt, oder sich dies nur auf eine kleine Anzahl an Anwendungen oder Anwendungsfälle bezieht.
  • Der Schweregrad enhancement sollte für Verbesserungen verwendet werden welche keine Fehler beheben, sowie für Pakete die neu aufgenommen werden sollen
  • Der Schweregrad normal sollte für alle anderen Fälle verwendet werden.

Hat die Fehlertruppe die Fehlerauswahl beendet, sollte das Schlüsselwort Triaged in den Fehler eingefügt werden.

Die Lösung durch den Betreuer

Wenn ein Problem eine Aktion von den Paketbetreuern benötigt und alle entsprechende Informationen vom Berichterstatter zur Verfügung gestellt wurden (mit der Hilfe der Fehlertruppe), so obliegt es nun dem Paketbetreuer diesen Fehler zu beheben. Die Betreuer können einen Fehler als RESOLVED FIXED markieren, wenn Sie eine Fehlerlösung gefunden und diese an den SVN abgegeben haben, aber für eine stabile Version endet hier die Zuständigkeit noch nicht. Für unterstützte Pakete, sollte auch sichergestellt werden, dass eine offizielle Aktualisierung veröffentlicht wird, abhängig von der Unterstützungspolitik der Nachlaufphase. Es ist erstrebenswert, dass ein Link der in der originalen Fehlermeldung berichtet wurde (wobei beide unterschiedlich sind) ebenfalls übernommen wird, so dass es dem Anwender möglich ist den Zustand der Aktualisierung zu verfolgen. Für nicht unterstützte Pakete ist es erstrebenswert, dass der Betreuer ein Aktualisierungspaket direkt in die entsprechenden Repositorys stellt.

Der Bereich an möglichen Aktionen, die benötigt werden, um Fehler zu beheben, geht weit über den Schwerpunkt dieses Dokuments hinaus. Ist das von Fehlern befreite Paket in der entsprechenden Repository verfügbar, so obliegt es dem Betreuer den Status für diesen Fehler auf RESOLVED FIXED zu setzen.

Die Möglichkeit des Betreuers einen Auswahlprozess kurzzuschließen

Es gibt einen Fall, bei dem man den oben beschriebenen Prozessen nicht folgen muss: Es ist für den Paketbetreuer möglich den Auswahlprozess zu umgehen und direkt den Fehler zu beheben.

Wenn ein Fehler noch nicht vollständig untersucht, der Paketbetreuer aber davon überzeugt ist, dass er die Fähigkeit besitzt diesen Fehler zu beheben, so kann er die Eigentümerschaft über diesen Fehler übernehmen. An diesem Punkt hat der Betreuer die Verantwortung übernommen das Problem, wie es gemeldet wurde, zu beheben und/oder für weitere Informationen beim Berichterstatter anzufragen. Dieser Fehler ist nicht länger im Verantwortungsbereich der Fehlertruppe, trotz der Tatsache dass der Auswahlprozess noch nicht vollständig abgeschlossen ist. Der Betreuer darf dann den Fehler nicht mehr an die Fehlertruppe zurückweisen.

VERIFIED und CLOSED

Der Status VERIFIED scheint aus unserem Betrachtungswinkel für den Prozess der Fehlerbehandlung nicht nützlich zu sein und deshalb ist es nicht nötig dass dieser Zustand im Mageia Bugzilla von irgendjemand verwendet wird. Wenn der Betreuer eine Fehlerbehebung als gelöst betrachtet, so markiert er diesen Fall mit RESOLVED FIXED. Wenn der Berichterstatter oder die Fehlertruppe wünscht die Lösung zu überprüfen, kann er es auf folgende Weise tun: wenn er bekräftigt dass dieser Fehler behoben ist, so lasse einfach den Zustand RESOLVED FIXED; ist der Fehler nicht behoben, so kannst du den Fehler wieder öffnen.

Anforderungen zur Erweiterung

Ein spezieller Fall im Prozess der Mageia-Fehlerverfolgung sind Anfragen bezüglich Paket-Erweiterung. Gültige Erweiterungsanforderungen enthalten Anforderungen für zusätzliche Eigenschaften/Funktionen für Software die von Mageia-Entwicklern geschrieben oder betreut wird, und Anregungen für Erweiterungen in aktuellen Paketen einer Software die nicht von Mageia-Entwicklern geschrieben oder betreut wird. Anforderungen an zusätzliche Eigenschaften der Software die nicht von Mageia-Entwicklern geschrieben oder betreut wird, zählen nicht als gültige Erweiterungsanforderung und werden unter dem obigen Abschnitt Dinge die keine Aktion vom Paketbetreuer benötigen beschrieben.

Die Zuständigkeit der Fehlertruppe ist im Falle einer Erweiterungsanforderung darauf beschränkt sicherzustellen, dass eine vollständige und nachvollziehbare Erklärung der angeforderten Eigenschaft vom Berichterstatter zur Verfügung gestellt wird, und das Feld Severity korrekt auf den Wert enhancement gesetzt ist. An diesem Punkt sollte die Fehlertruppe den Fehlerbericht dem entsprechenden Betreuer zuweisen.

Der Betreuer ist nicht gezwungen, eine Erweiterungsanforderung zu akzeptieren. Dies sind keine eigentlichen "Fehler" im Sinn der oben aufgeführten Definition und konsequenterweise entspricht es nicht unseren Grundsätzen, dass diese Erweiterungen in allen Fällen erfüllt werden. Der Betreuer kann entscheiden ob er diese Anforderungen akzeptiert oder nicht. Wählt der Betreuer dass er diese Anforderungen akzeptiert, dann sollte ein Kommentar eingefügt werden, der dies widerspiegelt, und ist diese Anforderung einmal in einem Paket implementiert das durch eine entsprechende Repository verfügbar ist, dann sollte der Fehlerstatus auf RESOLVED FIXED gesetzt werden. Wenn sich der Betreuer entschließt diese Anforderung nicht zu akzeptieren dann sollte ein Kommentar eingefügt werden, der diesen Entschluss erklärt, und der Fehlerstatus sollte auf RESOLVED WONTFIX gesetzt werden. Eine dieser beiden Entscheidungen löst diese Anfrage.