Informationen für Entwickler, die das Fehlerverwaltungssystem betreffen

Zunächst wird ein Fehlerbericht von einem Benutzer als eine normale E-Mail-Nachricht an submit@bugs.debian.org verschickt. Diese E-Mail bekommt dann eine Nummer, der Benutzer erhält eine Empfangsbestätigung und die Nachricht wird an debian-bugs-dist weitergeleitet. Wenn der Absender zusätzlich eine Paket-Zeile einfügt, die den Paketnamen und den Namen des Paketbetreuers enthält, dann erhält auch der Betreuer eine Kopie des Fehlerberichts.

Zu der Subject-Zeile wird noch Bug# nnn: hinzugefügt und das Reply-To wird so geändert, dass es beide, den Absender des Fehlerberichts und nnn@bugs.debian.org, enthält.

Fehlerberichte schließen

Fehlerberichte von Debian sollten geschlossen werden, wenn das Problem behoben ist. Probleme in Paketen können nur für behoben erachtet werden, wenn das Paket, das die Fehlerbehebung enthält, das Debian-Archiv erreicht.

Üblicherweise sind die einzigen Personen, die einen Fehlerbericht schließen sollten, der Einreicher des Fehlerberichts und der/die Betreuer des Paketes, gegen das der Fehler berichtet wurde. Es gibt Ausnahmen von dieser Regel, zum Beispiel, wenn der Fehler gegen unbekannte Pakete oder gewisse generelle Pseudo-Pakete berichtet wurde. Falls Sie Zweifel haben, schließen Sie den Fehler nicht, sondern fragen Sie zuerst auf der Mailingliste debian-devel um Rat.

Fehlerberichte sollten geschlossen werden, indem man eine E-Mail an nnn-done@bugs.debian.org schickt. Der Inhalt der E-Mail muss die Erklärung enthalten, wie der Fehler behoben wurde.

Alles, was Sie zum Schließen des Berichts tun müssen, ist eine Antwort auf die E-Mail zu schreiben, die Sie von der Fehlerdatenbank erhalten haben, und das To-Feld auf nnn-done@bugs.debian.org zu ändern (statt nnn-done kann man auch nnn-close verwenden).

Wo anwendbar, geben Sie eine Version-Zeile im pseudo-header Ihrer Nachricht ein, wenn Sie einen Fehler schließen, so dass die Fehlerdatenbank weiß, in welcher Veröffentlichung des Paketes die Korrektur enthalten ist.

Die Person, die den Fehler schließt, die Person, die den Fehlerbericht verfasst hat und die debian-bugs-closed Mailingliste bekommen alle eine Hinweis-E-Mail über die Änderungen im Status des Berichts. Der Einsender und die Mailingliste erhalten ebenfalls den Inhalt der Nachricht, die an nnn-done geschickt wurde.

Followup-Nachrichten

Die Fehlerdatenbank wird die Einsenderadresse und die Fehleradresse (nnn@bugs.debian.org) in der Reply-To-Kopfzeile nach dem Weiterleiten des Fehlerberichts aufnehmen. Bitte beachten Sie, dass dies zwei unterschiedliche Adressen sind.

Wenn ein Entwickler auf einen Fehlerbericht antworten möchte, sollten Sie einfach auf die Nachricht antworten und die Reply-To-Kopfzeile respektieren. Das wird den Fehlerbericht nicht schließen.

Die Fehlerdatenbank bekommt den Bericht über nnn@bugs.debian.org, stellt ihn dem Paketbetreuer zu, speichert die Antwort sowie den Rest des Fehlerprotokolls und leitet sie an debian-bugs-dist weiter.

Durch das Senden einer Nachricht an nnn-submitter@bugs.debian.org wird explizit eine E-Mail an den Einsender des Fehlers geschickt und eine Kopie in der Fehlerdatenbank platziert. Die Nachricht wird nicht an den Paketbetreuer geschickt.

Wenn Sie eine Followup-Nachricht schicken möchten, die nicht in debian-bugs-dist passt, dann können Sie es tun, indem Sie diese Nachricht an nnn-quiet@bugs.debian.org oder an nnn-maintonly@bugs.debian.org schicken. E-Mails an nnn-quiet@bugs.debian.org werden in der Fehlerdatenbank gespeichert, jedoch nicht an irgendwelche Einzelpersonen oder Mailinglisten weitergeleitet. E-Mails an nnn-maintonly@bugs.debian.org werden in der Fehlerdatenbank gespeichert und nur an den Betreuer des betroffenen Pakets weitergeleitet.

Benutzen Sie auf keinen Fall die an alle Empfänger antworten- oder die followup-Funktion Ihres E-Mail-Programms, es sei denn, Sie möchten die Liste der Empfänger grundsätzlich selbst überarbeiten. Achten Sie insbesondere darauf, dass Sie keine Followup-Nachrichten an submit@bugs.debian.org verschicken.

Hinsichtlich weiterer Informationen über Kopfzeilen, mittels denen ACK-Benachrichtigungen unterdrückt werden können, und darüber, wie mit Hilfe des Fehlerverwaltungssystems Kopien verschickt werden können, schauen Sie in die Anleitung zum Fehlereinreichen.

Schweregrad

Die Fehlerdatenbank speichert zusätzlich zu jedem Fehler einen Schweregrad. Diese wird standardmäßig auf normal gesetzt, was jedoch entweder durch das Hinzufügen einer Severity-Zeile im Pseudo-Header beim Verfassen des Fehlerberichts (siehe Anweisungen für Fehlerberichte) oder durch das Benutzen des severity Kommandos mit dem control request server geändert werden kann.

Die Schweregrade:

critical
Beschädigt Software im System, die in keinem Bezug zum fehlerhaften Paket steht, (oder sogar das ganze System) oder verursacht einen ernsthaften Datenverlust oder öffnet eine neue Sicherheitslücke auf dem System, auf dem Sie das Paket installieren.
grave
Macht das betreffende Paket (fast) unbrauchbar oder verursacht einen Datenverlust oder öffnet eine Sicherheitslücke, die es erlaubt, auf die Benutzerkonten derjenigen Benutzer zuzugreifen, die das Paket verwenden.
serious
Ist eine ernsthafte Verletzung der Debian Policy (bedeutet ungefähr, dass es eine muss- oder erfordert-Klausel verletzt) oder macht das Paket nach Meinung des Betreuers oder der Veröffentlichungsverwalter ungeeignet für eine Veröffentlichung.
important
Ein Fehler, der wesentliche Auswirkungen auf die Benutzbarkeit des Pakets hat, ohne es völlig unbrauchbar für jedermann zu machen.
normal
Standardwert, anwendbar auf die meisten Fehler.
minor
Ein Problem, das die Nützlichkeit des Pakets nicht beeinflusst, und das vermutlich sehr leicht zu beheben ist.
wishlist
Für beliebige Feature-Requests, aber auch für beliebige Fehler, die aufgrund wesentlicher konzeptioneller Erwägungen sehr schwer zu beheben sind.

Bestimmte Schweregrade werden als veröffentlichungskritisch erachtet, was bedeutet, dass der Fehler einen Einfluss auf die Veröffentlichung des Paketes mit dem stabilen Release von Debian hat. Im Augenblick sind das critical, grave und serious. Die vollständigen und kanonischen Regeln, welche Probleme diese Schweregrade rechtfertigen, sehen Sie in der Liste der veröffentlichungskritischen Probleme für Lenny.

Markierungen für Fehlerberichte

Jeder Fehler kann eine oder mehrere Markierungen (engl. Tags) aus einer gegebenen Menge haben. Diese Markierungen werden in der Liste der Fehler angezeigt, wenn Sie auf der Paket-Seite oder im vollständigen Fehlerprotokoll nachschauen.

Die Markierungen können durch das Einfügen einer Tags-Zeile in den Pseudo-Kopfzeilen beim Abschicken des Fehlerberichts (siehe Anweisungen für Fehlerberichte), oder durch das Benutzen des tags-Kommandos mit dem control request server gesetzt werden. Mehrere Markierungen können Sie durch Kommata, Leerzeichen oder beides trennen.

Die zurzeit verfügbaren Fehler-Markierungen:

patch
Ein Patch oder eine andere leichte Prozedur, die den Fehler behebt, ist im Fehlerprotokoll enthalten. Wenn es einen Patch gibt, der jedoch den Fehler nicht hinreichend behebt, oder irgendwelche andere Probleme verursacht, dann sollte diese Markierung nicht verwendet werden.
wontfix
Dieser Fehler wird nicht behoben. Möglicherweise weil es eine Wahl zwischen zwei beliebigen Arten Dinge zu erledigen gibt und der Paketbetreuer und der Absender des Fehlerberichts es vorziehen, Dinge auf ihre eigene Weise zu regeln, möglicherweise auch, weil die Änderung des Verhaltens andere, schlimmere Probleme nach sich ziehen würde oder aber auch wegen anderen Problemen.
moreinfo
Dieser Fehler kann nicht bearbeitet werden, bevor der Absender des Fehlerberichts mehr Informationen zur Verfügung stellt. Der Fehler wird für geschlossen erklärt, falls der Absender keine weiteren Informationen innerhalb eines angemessenen Zeitraumes (ein paar Monate) liefert. Das ist für Fehler der Art Das geht nicht. Was geht nicht?
unreproducible
Dieser Fehler kann nicht auf dem System des Paketbetreuers reproduziert werden. In diesem Fall wird die Hilfe einer Drittpartei in der Diagnose der Ursachen des Problems benötigt.
help
Der Paketbetreuer ersucht um Hilfe beim Beheben des Fehlers.
pending
Eine Lösung für dieses Problem wurde gefunden und ein repariertes Paket wird bald hochgeladen.
fixed
Dieser Fehler wurde behoben oder es existiert ein Workaround (der von einem Nicht-Betreuer eingereicht wurde), es gibt jedoch immer noch ein Randproblem, das beseitigt werden soll. Dieser Markierung ersetzt den alte Schweregrad fixed.
security
Dieser Fehler beschreibt ein Sicherheitsproblem in einem Paket (z.B. falsch gesetzte Rechte, die Zugriff auf Daten erlauben, auf die nicht zugegriffen werden sollte; Pufferüberlauf, der es den Leuten erlaubt, das System so zu kontrollieren wie sie es eigentlich nicht dürften; Diensteverweigerungs-Angriffe, die behoben werden sollten, usw.). Die meisten sicherheitsrelevanten Fehler sollten außerdem auch auf die critical- oder grave-Schwere gesetzt werden.
upstream
Dieser Fehler bezieht sich auf den Code-Teil des ursprünglichen Autors.
confirmed
Der Paketbetreuer hat den Fehlerbericht gelesen, verstanden und sieht ihn als korrekt an, hat den Fehler aber noch nicht behoben (Die Benutzung dieser Markierung ist optional; sie ist hauptsächlich für Betreuer gedacht, die eine große Anzahl offener Fehler verwalten müssen.).
fixed-upstream
Der Fehler wurde vom Upstream-Betreuer behoben, ist aber noch nicht im Paket enthalten (aus welchem Grund auch immer: möglicherweise ist es zu kompliziert, die Änderungen zurückzuportieren, oder der Fehler ist zu gering, um sich darüber den Kopf zu zerbrechen).
fixed-in-experimental
Der Fehler wurde in dem Paket behoben, das in der Experimental-Distribution enthalten ist, aber noch nicht in der Unstable-Distribution.
d-i
Dieser Fehler ist für die Entwicklung des debian-installer relevant. Diese Markierung sollte verwendet werden, wenn der Fehler die Entwicklung des Debian-Installers beeinflusst, das Paket, das davon betroffen ist, aber kein direkter Teil des Installers selbst ist.
ipv6
Dieser Fehler beeinträchtigt die Unterstützung für das Internet-Protokoll Version 6.
lfs
Dieser Fehler beeinträchtigt die Unterstützung großer Dateien (über 2 Gigabyte).
l10n
Dieser Fehler ist für die Lokalisierung des Pakets relevant.
potato
Dieser Fehler gilt insbesondere für die Potato-Veröffentlichung des Debian-Systems.
woody
Dieser Fehler gilt insbesondere für die Woody-Distribution.
sarge
Dieser Fehler sollte nicht archiviert werden, bis er in Sarge behoben ist.
sarge-ignore
Dieser veröffentlichungskritische Fehler soll zum Zwecke der Veröffentlichung von Sarge ignoriert werden. Diese Markierung sollte nur vom Veröffentlichungsleiter verwendet werden; setzen Sie sie nicht selbst ohne ausdrückliche Berechtigung von diesen.
etch
Dieser Fehler sollte nicht archiviert werden, bis er in Etch behoben ist.
etch-ignore
Dieser veröffentlichungskritische Fehler soll zum Zwecke der Veröffentlichung von Etch ignoriert werden. Diese Markierung sollte nur vom Veröffentlichungsleiter verwendet werden; setzen Sie sie nicht selbst ohne ausdrückliche Berechtigung von diesen.
lenny
Dieser Fehler sollte nicht archiviert werden, bis er in Lenny behoben ist.
lenny-ignore
Dieser veröffentlichungskritische Fehler soll zum Zwecke der Veröffentlichung von Lenny ignoriert werden. Diese Markierung sollte nur vom Veröffentlichungsleiter verwendet werden; setzen Sie sie nicht selbst ohne ausdrückliche Berechtigung von diesen.
sid
Dieser Fehler sollte nicht archiviert werden, bis er in Sid behoben ist.
experimental
Dieser Fehler sollte nicht archiviert werden, bis er in Experimental behoben ist.

Die Bedeutung der letzten acht Markierungen haben sich kürzlich geändert; die ignore-Markierungen ignorieren Fehler zum Zweck des Übergangs nach Testing. Die Veröffentlichungs-Markierungen, die bisher nur anzeigten, welche Fehler eine bestimmte Veröffentlichung betrafen, zeigen jetzt an, wann ein Fehler archiviert werden kann und werden andererseits von der Fehlerdatenbank ignoriert. Jedoch könnten sie von anderen Werkzeugen wie die Skripte zur Bestimmung, ob ein Paket nach Testing hochgeladen werden könnte, verwendet werden.

Aufzeichnen, dass Sie den Fehlerbericht weitergeleitet haben

Wenn ein Entwickler einen Fehlerbericht an den Entwickler des Upstream-Quellpakets, von dem das Debian-Paket abstammt, weiterleitet, dann sollte er das in der Fehlerdatenbank wie folgt vermerken:

Stellen Sie sicher, dass das To-Feld Ihrer Nachricht zum Autor nur die Adresse(n) des Autors/der Autoren enthält; fügen Sie die Person, die den Fehler gemeldet hat, nnn-forwarded@bugs.debian.org und nnn@bugs.debian.org in das CC-Feld ein.

Bitten Sie den Autor das CC an nnn-forwarded@bugs.debian.org beim Antworten stehen zu lassen, so dass die Fehlerdatenbank die Antwort des Autors mit dem Originalfehlerbericht zusammen protokollieren kann. Diese Nachrichten werden nur abgelegt und nicht weitergeleitet; um eine Nachricht normal zu senden, schicken Sie sie auch an nnn@bugs.debian.org.

Wenn die Fehlerdatenbank eine Nachricht an nnn-forwarded erhält, dann wird der relevante Fehler als weitergeleitet markiert, die Weiterleitungsadresse ist dann die Adresse aus dem To-Feld der Originalnachricht die die Datenbank bekommt, falls der Fehler nicht bereits als weitergeleitet markiert ist.

Sie können auch die forwarded to-Information manipulieren, indem Sie eine Nachricht an control@bugs.debian.org abschicken.

Besitzer eines Fehlers ändern

Wenn die Person, die für die Fehlerbehebung verantwortlich ist, nicht der zugewiesene Betreuer des Pakets ist (zum Beispiel, wenn das Paket von einer Gruppe betreut wird), kann es nützlich sein, diese Tatsache im Fehlerverwaltungssystem festzuhalten. Um dabei zu helfen, kann jeder Fehler wahlweise einen Besitzer haben.

Der Besitzer kann beim Senden eines Fehlerberichts durch eine Owner-Zeile in den Pseudo-Kopfzeilen festgelegt werden (siehe die Anweisungen, wie Fehler berichtet werden) oder durch die Verwendung der Befehle owner und noowner im Zusammenhang mit dem control request server.

Falsch angezeigte Paketbetreuer

Wenn ein Paketbetreuer falsch angezeigt wird, dann liegt es meistens daran, dass sich der Paketbetreuer vor kurzem geändert hat und der neue Betreuer es versäumt hat, eine neue Version des Pakets mit einem abgeänderten Maintainer-Feld in der Kontrolldatei hochzuladen. Das wird behoben sobald das Paket hochgeladen wird; als Alternative können die Archivbetreuer den Betreuereintrag per Hand ändern, zum Beispiel wenn ein neues Build oder ein erneutes Hochladen des Paket nicht in nächster Zukunft zu erwarten ist. Setzen Sie sich mit override-change@debian.org in Verbindung, um Änderungen an der override-Datei zu veranlassen.

Wiedereröffnung, Neuzuweisung und Manipulation von Fehlerberichten

Es ist möglich, Fehlerberichte anderen Paketen zuzuweisen, fälschlicherweise für geschlossen erklärte Fehler neu zu eröffnen, die Information über das Ziel der Weiterleitung (falls eine existiert) eines Fehlerberichts zu modifizieren, Schweregrade und Titel der Berichte zu ändern, den Besitzer eines Fehlers festzulegen, Fehlerberichte zu verschmelzen bzw. wieder auseinander zu ziehen und die Versionen des Paketes, in der der Fehler gefunden und in der er behoben wurde, festzuhalten. Das können Sie machen, indem Sie eine Nachricht an control@bugs.debian.org senden.

Das Format dieser Nachrichten ist in einem anderen Dokument, das entweder im WWW oder in der Datei bug-maint-mailcontrol.txt verfügbar ist, beschrieben. Eine Volltextversion kann auch durch das Senden des Wortes help an den oben genannten Server erhalten werden.

Fehler abonnieren

Die Fehlerdatenbank erlaubt den Fehler-Berichtern, Entwicklern und anderen interessierten dritten Parteien individuelle Fehler zu abonnieren. Diese Fähigkeit kann von denen verwendet werden, die ein Auge auf einem Fehler haben wollen ohne das gesamte Paket über das PTS zu abonnieren. Alle Nachrichten, die bei nnn@bugs.debian.org empfangen werden, werden an die Abonnenten geschickt.

Ein Fehler kann durch Versand einer E-Mail an nnn-subscribe@bugs.debian.org abonniert werden. Der Betreff und der Textkörper der E-Mail werden vom BTS ignoriert. Sobald diese Nachricht verarbeitet wurde, werden den Benutzern eine Bestätigung-E-Mail zugestellt, auf die sie antworten müssen bevor ihnen die Nachrichten, die den Fehler betreffen, zugeschickt werden.

Es ist auch möglich, das Abonnement eines Fehlers zu beenden. Dies kann über eine E-Mail an nnn-unsubscribe@bugs.debian.org erfolgen. Der Betreff und der Textkörper der E-Mail werden wieder vom BTS ignoriert. Den Benutzern wird eine Bestätigungsnachricht übersandt, die sie beantworten müssen, falls sie das Abonnement des Fehlers beenden wollen.

Standardmäßig wird die Adresse abonniert, die in der From-Kopfzeile gefunden wird. Falls Sie für eine andere Adresse den Fehler abonnieren wollen, müssen Sie die Adresse, auf die der Fehler abonniert werden soll, in die Abonnier-Nachricht kodieren. Dies erfolgt in der Form: nnn-subscribe-Lokalteil=beispiel.com@bugs.debian.org. Dieses Beispiel würde Lokalteil@beispiel.com eine Abonniermeldung für Fehler nnn schicken. Das @-Zeichen muss durch Änderung in ein =-Zeichen kodiert werden. Ähnlich nimmt die Beendigung des Abonnements die Form nnn-unsubscribe-Lokalteil=beispiel.com@bugs.debian.org an. In beiden Fällen werden der Betreff und der Textkörper der E-Mail an die E-Mail-Adresse, die in der Anforderung einkodiert ist, im Rahmen der Bestätigungsanfrage weitergeleitet.

Das mehr oder weniger veraltete subject-scanning-Feature

Nachrichten, die beim submit oder bei bugs ankommen und deren Betreffzeile mit Bug#nnn anfängt, werden so behandelt, als wären sie an nnn@bugs.debian.org geschickt worden. Das passiert, um Abwärtskompatibilität zu den Nachrichten, die von alten Adressen weitergeleitet wurden, zu erhalten, sowie dazu, Nachrichten abzufangen, die irrtümlich an submit geschickt wurden (z.B. durch das Benutzen der an alle Empfänger antworten-Funktion des jeweiligen E-Mailprogramms).

Ein ähnliches Schema gilt auch für maintonly, done, quiet und forwarded, die ankommende E-Mails mit einer Betreff-Markierung so behandeln, als wären sie zu der entsprechenden nnn-wasauchimmer@bugs.debian.org-Adresse geschickt worden.

Nachrichten, die nur mit forwarded und done – das heißt ohne die Nummer des Fehlerberichts in der Adresse und ohne Fehlernummer in der Betreffzeile – verschickt werden, werden unter junk einsortiert und für ein paar Wochen gespeichert, ansonsten jedoch ignoriert.

Veraltetes X-Debian-PR: quiet Feature

Früher war es möglich, die Fehlerdatenbank davon abzuhalten, die Nachrichten, die es an die debian-bugs Adresse bekam, irgendwohin weiterzuleiten, indem man die Zeile X-Debian-PR: quiet in die eigentlichen E-Mail-Kopfzeilen einfügte.

Diese Kopfzeile wird nun ignoriert. Stattdessen können Sie Ihre Nachricht an quiet oder nnn-quiet (oder maintonly bzw. nnn-maintonly) schicken.

Weitere Seiten der Fehlerdatenbank:

Debian BTS administrators <owner@bugs.debian.org>

Debian bug tracking system
Copyright © 1999 Darren O. Benham, 1997, 2003 nCipher Corporation Ltd, 1994-1997 Ian Jackson.