Policies/Bug policy

Aus Mandriva Community Wiki

Wechseln zu: Navigation, Suche
Welcome to the Mandriva Wiki,
a free documentation project that you can improve. 		122 Artikel auf Deutsch.

Inhaltsverzeichnis • Einen Account erstellen• Installation • Hilfe erhalten • #Help and contribute helfen und mitarbeiten



Dieses Dokument beschreibt den Vorgang, wie mit Bugreports (also Berichte über gefundene Bugs, zur Definition von Bug siehe unten) in Bezug auf Mandriva-Linux umzugehen ist. Zu beachten ist hierbei, dass dies nur die Hauptproduktlinie der Mandriva Linux Distribution (einschließlich der Free-, One-, Discovery-, Powerpack+ und Powerpack-Versionen) betrifft. Hier nicht behandelt wird die zur Benutzung in Unternehmen gedachte Produktlinie (Multi Network Firewall, Corporate Server- und Corporate Desktop-Version). In diesem Text sollen die Verantwortlichkeiten aller an einem Bugreport beteiligten Parteien (also des Meldenden, der Bug Squad-Mitglieder und der Maintainer (also des Betreuers des entsprechenden Softwarepaketes)) geklärt und alle möglichen Eventualitäten abgedeckt werden, damit jederzeit klar ist, wer was zu tun hat, um einen Bug zu beseitigen.

Inhaltsverzeichnis

Definition

Ein Bug ist definiert als ein Fall, in dem eine Komponente einer Mandriva Linux-Distribution (oder eines anderen Produktes, das von Bugzilla behandelt wird, beispielsweise die Mandriva Webseite) an der Erfüllung des ihr angedachten Zweckes scheitert.

Vorgehensweise

Jeder Benutzer der Distribution darf (und sollte!) Bugs von Mandriva Linux melden. Mandriva bemüht sich, alle Bugs, die gemeldet werden, abzuarbeiten. Dies bedeutet nicht unbedingt, dass alle Bugs in der von dem Meldenden bevorzugten Weise gelöst werden, dies wird aber angestrebt, soweit die Möglichkeit dazu besteht. Es wird, soweit möglich, versucht, mit hinfälligen oder formal falschen Bugs in richtiger Weise zu verfahren und stichhaltige Bugs aufzulösen.

Dies bedeutet auch, dass als legitim erkannte Bugreports über unterstütze Pakete soweit möglich aufgeklärt werden müssen. Können diese Probleme nicht beseitigt werden, ist eine vollständige Erklärung der Umstände vonnöten. Sowohl die Behebung des Bugs als auch die Erklärung, wieso diese Behebung nicht möglich ist, stellen eine Lösung des Bugs dar. Wenn Bugreports in doppelter Ausfertigung vorliegen, formal falsch oder anderweitig hinfällig sind (beispielsweise, weil das Problem ausserhalb der Zuständigkeit der Fehlerbeheber liegt) oder das Nachvollziehen sich als unmöglich erweist, muss der entsprechende Bug (mit entsprechender Änderung des Status) als RESOLVED (also "gelöst") markiert werden und entweder von dem Maintainer des Paketes oder einem Mitglied der Bug Squad mit einer ausführlichen Erklärung versehen werden. Dieses Ergebnis ist einer Lösung des Bugs gleichzusetzen. Keine anderen Ergebnisse sollen mit einer Lösung des Problems gleichgesetzt werden.

Bugs melden

Bugs werden bei Bugzilla gemeldet. Dabei muss der Meldende die entsprechende Distribution und das dazugehörige Produkt auswählen. Ein Bugreport sollte aus einer vollständigen Beschreibung des Problems und, wo erforderlich, einer detaillierten Schritt-für-Schritt-Anleitung zur Rekonstruktion des Bugs bestehen ("Was muss man tun, um den Fehler hervorzurufen"). Außerdem sollten alle relevanten Informationen in Bezug auf die Hardware- und Softwareumgebung zur Erzeugung des Fehlers angegeben werden, also besondere Hardware, spezielle Softwarepakete oder besondere Einstellungen. Hinweise zur Fehlerbehebung, Patches eingeschlossen, sind willkommen, aber keine Voraussetzung.

Abstimmen

Jeder, der einen Bugzilla-Account hat, kann für einen bestimmten Bug stimmen. Auf diese Weise wird das Interesse für bestimmte Bugs und deren Behebung gemessen. Maintainer sollten die Stimmen (neben der Schwere und Priorität des Bugs) als einen Faktor für das Management ihrer mit der Fehlerbehebung verbrachten Arbeitszeit ansehen und als Überwachungswerkzeug gebrauchen.


Unbeliebteste Bugs (nach Stimmen) Bugs

Am meisten gewollt / Beliebteste Bugs (nach Stimmen) Features

Das Triage-Team

Anfangs befinden alle Bugs im Verantwortungsbereich des Triage-Teams. Das Triage-Team hat zwei Hauptverantwortlichkeiten: Erstens muss das Triage-Team entscheiden, ob bei einem Aspekt Handlungsbedarf vonseiten des Paketmaintainers besteht.

Aspekte, bei denen kein Handlungsbedarf vonseiten des Paketmaintainers besteht

In den folgenden Fällen besteht kein Handlungsbedarf vonseiten des Paketmaintainers. Ist dies der Fall, ist es die Aufgabe des Triage-Teams, das Problem zu lösen.

  • Der Bug ist das Duplikat eines bereits existierenden Bugreports. Dies bedeutet, dass bei demselben Produkt derselben Ausgabe dasselbe Problem bereits bekannt ist. Berichte über dasselbe Problem in verschiedene Ausgaben (also z.B. in Mandriva Linux 2009.0 und 2009.1) gelten nicht als Duplikate. Die Mitglieder des Triage-Teams sollten Duplikate mit dem RESOLVED DUPLICATE-Status (also in etwa "Erledigt, Duplikat") versehen. Dies gilt als Lösung des Problems.
  • Das Problem ist kein Bug nach obiger Definition. Dies wäre beispielsweise der Fall, wenn ein Bugreport zusätzliche Features an einem Teil einer Software fordert, die nicht von dem Mandriva Entwicklungsteam betreut wird oder wenn ein Bug auf das Fehlverhalten des Benutzers zurückzuführen ist. Die Mitglieder des Triage-Teams sollen den Status dieser nicht die Kriterien eines Bugs erfüllenden Meldungen auf RESOLVED INVALID ("Erledigt, ungültig") oder RESOLVED WONTFIX ("Erledigt, [wir] werden es nicht beheben") ändern, ausser, wenn eine legitime Bitte zur Erweiterung des Berichts (dies wird unten weiter beschrieben) vorliegt. All dies gilt als Lösung des Problems.
  • Das Problem ist kein Duplikat und erfüllt die Kriterien eines Bugs, wäre aber besser an anderer Stelle der Software-Entwicklung aufgehoben. Einige Problem können auf der Stufe der Distributionspakete nicht sinnvoll gelöst werden, z.B. grundlegende Fehler in dem Code einer Anwendung. In diesem Fall werden Mitglieder des Triage-Teams den Meldenden mit der Bitte um erneute Meldung des Fehlers mithilfe der bestgeeignetsten Methode an die entsprechende (höhere) Stelle verweisen. Beispielsweise könnte der Meldende gebeten werden, den Bug bei GNOME Bugzilla zu melden, wenn es sinnvoller ist, sich dort mit dem Bug zu beschäftigen. Ist dies erledigt, sollten Mitglieder des Triage-Teams oder der Meldende den Mandriva Bugreport auf RESOLVED REPORTEDUPSTREAM ("Erledigt, bei höherer Stelle gemeldet") umstellen und einen Direktlink auf diesen Bugreport einfügen. Bei Bugs, die Cooker betreffen, gilt dies als Lösung des Problems, weil angenommen wird, dass, sobald der Bug an der höheren Stelle (in unserem Beispiel beim GNOME Entwicklungsteam) gelöst wurde, diese Lösung baldmöglichst in Mandriva Linux integriert werden wird. Bei Bugs, die die "stable"-Versionen betreffen, gilt das Melden des Fehlers bei einer höheren Stelle nur als vorläufige Lösung des Problems, weil neue Versionen nicht routinemäßig in neuen "stable"-Ausgaben eingefügt werden. Sobald der Bug bei der höheren Stelle gelöst wurde, kann das Triage-Team oder der den ursprünglichen Bug Meldende den Bugreport wiedereröffnen und ebendieser Bugreport wird dann daraufhin untersucht, ob es sinnvoll ist, die Lösung der höheren Stelle in ein Update der Ausgabe von Mandriva einzuschließen.

Aspekte, bei denen Handlungsbedarf vonseiten des Paketmaintainers besteht

Probleme, die nicht in eine der oben genannten Kategorien fallen - also Probleme, die die Kriterien eines Bugs erfüllen, deren Berichte nicht als Duplikate vorliegen, die nachvollziehbar sind und die sinnvoll auf der Stufe der Distributionspakete gelöst werden können - sind gültige (engl. "valid") Bugs, bei denen Handlungsbedarf vonseiten des Paketmaintainers besteht. In diesem Fall ist es die Aufgabe des Triage-Teams, sicherzustellen, dass alle relevanten Informationen (siehe den Abschnitt "Bugs melden" weiter oben) von dem Meldenden eingeholt, die Felder priority ("Priorität") und severity (in etwa "Schwere des Fehlers") korrekt ausgefüllt werden und der Status des Bugs auf ASSIGNED ("Jemandem zugewiesen") gestellt und die Aufgabe der Fehlerbehebung dem zuständigen Maintainer zugewiesen wird. In keinem Fall sollten Mitglieder des Triage-Teams Maintainern Bugreports mit unvollständigen Informationen zuweisen.

Sind bereits in der ersten Meldung eines Bugs alle benötigten Informationen enthalten, kann der Bug einfach als ASSIGNED ("Jemandem zugewiesen") markiert und sofort dem zuständigen Maintainer zugewiesen werden. Ab diesem Punkt liegt die Verantwortung über den Bug bei dem Maintainer.

Sind in der ersten Meldung des Bugs nicht alle benötigten Informationen enthalten, sollten Mitglieder des Triage-Teams das Schlagwort NEEDINFO ("Brauche Info") und einen Kommentar hinzufügen, in dem der den Bug Meldende exakt darüber aufgeklärt wird, welche Informationen noch benötigt werden und wie er diese Informationen erhält (dies kann mit einer Schritt-für-Schritt-Anleitung erfolgen, aber auch durch die Verlinkung auf eine Anleitung). Solange dies nicht erfolgt ist, befindet sich der Bug im Verantwortungsbereich des Triage-Teams. Wurde der Meldende über die fehlenden Informationen aufgeklärt, liegt die Verantwortung bei dem Meldenden, bis dieser die erforderlichen Informationen zur Verfügung gestellt hat. Sollte es dem Meldenden nicht möglich sein, innnerhalb einer angemessenen Zeitspanne diese Informationen zur Verfügung zu stellen, oder der Meldende artikuliert, dass er die gewünschten Informationen nicht zur Verfügung stellen kann, wird das Problem zu einem, bei dem kein Handlungsbedarf vonseiten des Paketmaintainers besteht und sollte entsprechend von dem Triage-Team bearbeitet werden.

Das Triage-Team muss bei jedem Bug außerdem die Felder priority ("Priorität") und severity (in etwa "Schwere des Fehlers") korrekt ausfüllen. Weil die Maintainer diese Felder dazu benutzen, ihre mit der Fehlerbehebung verbrachte Arbeitszeit einzuteilen, ist die Exaktheit dieser Felder sehr wichtig. Das Feld priority zeigt, wie dringend die Behebung dieses Bugs, also, wie wichtig der Bug in Bezug auf die Distribution als Ganzes ist. Das Feld severity deutet an, wie schwerwiegend der Bug in Bezug auf das Paket ist. Ein kritischer Bug eines selten benutzten Pakets kann also die Severity/Schwere-Einstufung critical erhalten, aber trotzdem bei der Priorität als low (also "gering") gelten, während ein kleiner, aber sehr auffälliger Bug in einem häufig verwendeten Paket zwar bei der Severity/Schwere als minor (also "unbedeutend"), bei der Priorität aber als release_critical (also "wichtig für diese Ausgabe") eingestuft werden kann.

Der Prioritätsstatus release_critical ist nur für Bugs im Cooker oder bei Betaversionen relevant und sollte nur gesetzt werden, wenn die Gesamtqualität der Ausgabe ohne die Behebung dieses Fehlers maßgeblich gemindert wäre. Die Priorität high (also "hoch") wird benutzt, wenn die Lösung dieses Problems so wichtig ist, dass sie Vorrang vor der Lösung anderer Probleme haben sollte, aber nicht als release_critical markiert wurde. Low (also "niedrig") wird als Priorität angegeben, wenn der entsprechende Bug simpel ist und/oder die Auswirkungen nur sehr begrenzt sind, so dass die Lösung anderer Problem Vorrang haben sollte. Alle anderen Bugs werden mit der Priorität normal versehen.

Der Schwere-Status critical (also "kritisch" bzw. "ausschlaggebend") wird für Bugs verwendet, die ein Paket unbenutzbar machen, beispielsweise Abstürze, die bei diesem Paket häufig auftreten oder die Unmöglichkeit der Installation oder Ausführung des Paketes. Den Schwere-Grad major (also "wichtig") verwendet man für Fehler, die eine wichtige Funktion eines Paketes unbenutzbar oder das Paket generell unstabil machen. Der Grad minor ("weniger wichtig") wird benutzt für Probleme, die nur begrenzte Auswirkungen auf die Benutzbarkeit des Paketes haben oder die nur eine kleine Minderheit der Benutzer betrifft, während die Einstufung trivial ("simpel") für Fehler vorgenommen wird, die praktisch keine Auswirkung auf die Benutzbarkeit des Paketes haben. Alle anderen Probleme werden mit dem Schwere-Gradnormal markiert.

Sobald das Triage-Team einen Bug fertig bearbeitet hat, fügt es das entsprechende Schlüsselwort zu dem Bug hinzu.

Lösung durch den Maintainer

Ein Problem, bei dem Handlungsbedarf vonseiten des Paketmaintainers besteht und mithilfe des Triage-Teams die notwendigen Informationen von dem den Fehler Meldenden bereitgestellt wurde, unterliegt dem Verantwortungsbereich des Paketmaintainers. Hat dieser eine Lösung des Problems gefunden und bei SVN abgeliefert, kann er den Bug als RESOLVED FIXED ("Erledigt, repariert") markieren, aber in Bezug auf die "stable"-Ausgaben ist er damit noch in aus der Verantwortung entlassen. Bei unterstützten Paketen sollte er ausserdem sicherstellen, dass ein offizielles Update veröffentlicht wird, das der Post-release support policy entspricht. Wünschenswert wäre es, in dem ursprünglichen Bugreport einen Link zu setzen auf die Warteliste der Updates, damit die Nutzer den Status des Updates im Auge behalten können. Bei nicht unterstützten Paketen ist es wünschenswert, dass der Maintainer direkt in dem entsprechenden Repository ein aktualisiertes Paket einstellt.

In diesem Text können natürlich nicht alle Handlungen, die notwendig sind, um Bugs zu lösen, darstellbar. Sobald das aktualisierte Paket in dem entsprechenden Repository verfügbar ist, ist es die Verantwortung des Maintainers, den Status des Bugs auf RESOLVED FIXED (also "Erledigt, repariert") zu ändern.

Recht des Maintainers auf Abkürzung der Evaluation durch das Triage-Team

In einem Fall muss der obenstehende Prozess nicht ausgeführt werden: Wenn der Paketmaintainer sich sicher ist, dass er den entsprechenden Bug lösen kann, bevor dieser vom Triage-Team bearbeitet worden ist, kann der Maintainer den Bug übernehmen. Der Maintainer übernimmt dann die Verantwortung für die Lösung dieses Bugs und gegebenenfalls das Auftreiben weiterer Informationen von dem Meldenden. Der Bug befindet sich damit nicht mehr im Verantwortungsbereich des Triage-Teams, obwohl der Triage-Prozess ja eigentlich nicht abgeschlossen worden ist. Der Maintainer kann in diesem Fall den Bug nicht an das Triage-Team zurückgeben.

VERIFIED ("Geprüft") und CLOSED ("Geschlossen")

Sowohl der Status VERIFIED als auch CLOSED wird beim Abarbeiten der Bugs nicht als hilfreich angesehen und deshalb wird von der Benutzung dieser Markierungen auf Mandriva Bugzilla abgeraten. Sollte der Maintainer ein Problem als gelöst ansehen, so wird er den Bug als RESOLVED FIXED markieren. Will der Meldende oder die Bug Squad sich vergewissern, dass der Bug erledigt ist, können sie dies tun - ergibt sich, dass der Bug gelöst ist, bleibt der Status auf RESOLVED FIXED, ist dies nicht der Fall, wird der Bugreport wieder geöffnet.

Enhancement requests / Wünsche nach Erweiterungen

Wichtig im Fehlerbeseitigungsprozess sind bei Mandriva auch die Wünsche nach neuen Features. Gültige Wünsche enthalten dabei Forderungen zusätzlicher Features in Software, die von Mandriva-Entwicklern geschrieben oder unterhalten wird und Empfehlungen von Erweiterungen beim Packen von Paketen, die nicht von Mandriva-Entwicklern geschrieben oder unterhalten wird. Wünsche nach zusätzlichen Features bei Software, die nicht von Mandriva-Entwicklern geschrieben oder unterhalten wird, gelten nicht als valide Enhancement Requests und werden wie die Problem im Kapitel 'Aspekte, bei denen kein Handlungsbedarf vonseiten des Paketmaintainers besteht' (siehe oben) behandelt.

Der Aufgabenbereich des Triage-Teams ist bei Erweiterungswünschen beschränkt auf die Sicherstellung, dass der Meldende eine vollständige und verständliche Erklärung des Funktionswunsches beifügt und das Severity/Schwere-Grad-Feld korrekt auf enhancement (also "Erweiterung") gesetzt wird. Zu diesem Zeitpunkt sollte das Triage-Team den Bug auf ASSIGNED ("jemandem zugewiesen") setzen und den Bug an den zuständigen Maintainer weiterleiten.

Der Maintainer ist nicht dazu verpflichtet, Erweiterungswünsche anzunehmen. Davon ausgenommen sind Bugs, wie sie oben definiert wurden und daraus folgend kann nicht garantiert werden, dass Erweiterungswünsche in jedem Fall berücksichtigt werden. Es ist Sache des Maintainers, ob er den Erweiterungswunsch akzeptiert oder nicht. Akzeptiert der Maintainer den Erweiterungswunsch, sollte er dies in den Kommentaren vermerken und dann nach Fertigstellung der Erweiterung diese über die entsprechenden Repositories zur Verfügung stellen und daraufhin den Status des Bugs/Erweiterungswunschs auf RESOLVED FIXED stellen. Akzeptiert der Maintainer den Erweiterungswunsch nicht, sollte er die Gründe für diese Entscheidung in einem Kommentar darlegen und den Status des Reports auf RESOLVED WONTFIX setzen. Alle der genannten Ausgänge gelten als Lösung des Problems.

Von „http://wiki.mandriva.com/de/Policies/Bug_policy“
Persönliche Werkzeuge
Fund the Mandriva Linux project
Andere Sprachen