path: root/german/Bugs/Developer.wml

#use wml::debian::template title="Debian BTS – Entwicklerinformationen" NOHEADER=yes NOCOPYRIGHT=true
#include "$(ENGLISHDIR)/Bugs/pkgreport-opts.inc"
#use wml::debian::translation-check translation="859f960fa633147bac5504a51b2e29800627217a"
# $Id$
# Translator: Igor Stroh <jenner@wohnheim.uni-ulm.de>
# Updated: Holger Wansing <linux@wansing-online.de>, 2011 - 2018.

<h1>Informationen über das Fehlerverwaltungssystem für Paketbetreuer
und Leute, die mit dem Sichten von Fehlern beschäftigt sind</h1>

<p>Eingangs wird ein Fehlerbericht als
normale E-Mail-Nachricht an <code>submit@bugs.debian.org</code>
eingeschickt. Diese muss zwingend eine <code>Package:</code>-Zeile
enthalten (Näheres unter <a href="Reporting">Debian BTS &ndash;
Fehler berichten</a>).
Der Fehler bekommt dann eine Nummer, der Einsender
erhält eine Empfangsbestätigung und die Nachricht wird an
<code>debian-bugs-dist</code> weitergeleitet. Wenn die
<code>Package</code>-Zeile den Namen eines Pakets mit bekanntem
Betreuer enthält,
dann erhält auch der Betreuer eine Kopie des Fehlerberichts.</p>

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

<ul class="toc">
  <li><a href="#closing">Fehlerberichte schließen</a></li>
  <li><a href="#followup">Folge-Nachrichten</a></li>
  <li><a href="#severities">Schweregrad</a></li>
  <li><a href="#tags">Markierungen für Fehlerberichte</a></li>
  <li><a href="#forward">Aufzeichnen, dass Sie den Fehlerbericht
    weitergeleitet haben</a></li>
  <li><a href="#owner">Besitzer eines Fehlers ändern</a></li>
  <li><a href="#maintincorrect">Falsch angezeigte Paketbetreuer</a></li>
  <li><a href="#requestserv">Wiedereröffnung, Neuzuweisung und Manipulation von
    Fehlerberichten</a></li>
  <li><a href="#subscribe">Fehler abonnieren</a></li>
  <li><a href="#subjectscan">Das mehr oder weniger veraltete
  subject-scanning-Feature</a></li>
  <li><a href="#x-debian-pr">Das veraltete <code>X-Debian-PR: quiet</code>-Feature</a></li>
</ul>


<h2><a name="closing">Fehlerberichte schließen</a></h2>

<p>Fehlerberichte von Debian sollten geschlossen werden, wenn das Problem
behoben ist. Probleme in Paketen können nur als behoben erachtet werden, wenn
das Paket, das die Fehlerbehebung enthält, das Debian-Archiv erreicht.</p>

<p>Ü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.</p>

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

<p>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 <code>To</code>-Feld auf
<var>nnn</var><code>-done@bugs.debian.org</code> ändern
(statt <var>nnn</var><code>-done</code> kann man auch
<var>nnn</var><code>-close</code> verwenden).</p>

<p>Wo anwendbar, geben Sie eine <code>Version</code>-Zeile in den <a
href="Reporting#pseudoheader">Pseudo-Kopfzeilen</a> Ihrer Nachricht an, wenn
Sie einen Fehler schließen, so dass die Fehlerdatenbank weiß, in welcher 
Veröffentlichung des Paketes die Korrektur enthalten ist.
</p>

<p>Die Person, die den Fehler schließt, die Person, die den Fehlerbericht
verfasst hat und die <code>debian-bugs-closed</code>-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 <var>nnn</var><code>-done</code> geschickt wurde.</p>


<h2><a name="followup">Folge-Nachrichten</a></h2>

<p>Die Fehlerdatenbank wird die Adresse des Einreichers und die Fehleradresse
(<var>nnn</var><code>@bugs.debian.org</code>) in die <code>Reply-To</code>-Kopfzeile
aufnehmen, nachdem der Fehlerbericht weitergeleitet wurde. Bitte beachten Sie,
dass dies zwei unterschiedliche Adressen sind.</p>

<p>Jeder Entwickler, der auf einen Fehlerbericht antworten möchte, sollte
einfach unter Respektierung der <code>Reply-To</code>-Kopfzeile
auf die Nachricht antworten. Das wird den Fehlerbericht <strong>nicht</strong>
schließen.</p>

<p>Benutzen Sie <em>auf keinen Fall</em> die <q>Allen
antworten</q>- oder die <q>followup</q>-Funktion Ihres E-Mail-Programms, es sei
denn, Sie möchten die Liste der Empfänger anschließend selbst überarbeiten.
Achten Sie insbesondere darauf, dass Sie keine Folge-Nachrichten an
<code>submit@bugs.debian.org</code> verschicken.</p>

<p>
Nachrichten können an die folgenden Adressen geschickt werden, um in der
Fehlerdatenbank abgelegt zu werden:
</p>

<ul>
<li>
<var>nnn</var><code>@bugs.debian.org</code> &ndash; solche Nachrichten werden
auch an den Paketbetreuer geschickt und an <code>debian-bugs-dist</code>
weitergeleitet, jedoch <strong>nicht</strong> an den Einreicher;
</li>
<li>
<var>nnn</var><code>-submitter@bugs.debian.org</code> &ndash; diese Nachrichten
werden auch an den Einreicher geschickt und an <code>debian-bugs-dist</code>
weitergeleitet, jedoch <strong>nicht</strong> an den Paketbetreuer;
</li>
<li>
<var>nnn</var><code>-maintonly@bugs.debian.org</code> &ndash; diese werden nur
an den Paketbetreuer geschickt, <strong>nicht</strong> an den Einreicher oder an
<code>debian-bugs-dist</code>;
</li>
<li>
<var>nnn</var><code>-quiet@bugs.debian.org</code> &ndash; diese werden nur
in der Fehlerdatenbank gespeichert (wie alle anderen oben erwähnten auch),
aber <strong>nicht</strong> an irgendjemanden sonst weitergeleitet.
</li>
</ul>

<p>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
<a href="Reporting">Anleitung zum Einreichen von Fehlerberichten</a>.</p>


<h2><a name="severities">Schweregrad</a></h2>

<p>Die Fehlerdatenbank speichert zusätzlich zu jedem Fehler einen
Schweregrad. Dieser wird standardmäßig auf <code>normal</code>
gesetzt, was jedoch entweder durch das Hinzufügen einer
<code>Severity</code>-Zeile im Pseudo-Header beim Verfassen des
Fehlerberichts (siehe <a href="Reporting#pseudoheader">Anweisungen für
Fehlerberichte</a>) oder durch das Benutzen des <code>severity</code>-Kommandos
über den <a href="#requestserv">Control Request Server</a>
geändert werden kann.</p>

<p>Die Schweregrade:</p>

<dl>
<dt><code>critical</code></dt>
<dd>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.</dd>

<dt><code>grave</code></dt>
<dd>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.</dd>

<dt><code>serious</code></dt>
<dd>Ist eine <a href="$(DOC)/debian-policy/">\
ernsthafte Verletzung der Debian Policy</a> (bedeutet ungefähr, dass
es eine <q>muss</q>- oder <q>erfordert</q>-Klausel verletzt) oder macht das Paket
nach Meinung des Betreuers oder der Veröffentlichungsverwalter ungeeignet für eine Veröffentlichung.</dd>

<dt><code>important</code></dt>
<dd>Ein Fehler, der wesentliche Auswirkungen auf die Benutzbarkeit des
Pakets hat, ohne es völlig unbrauchbar für jedermann zu machen.</dd>

<dt><code>normal</code></dt>
<dd>Standardwert, anwendbar auf die meisten Fehler.</dd>

<dt><code>minor</code></dt>
<dd>Ein Problem, das die Nützlichkeit des Pakets nicht beeinflusst, und das
vermutlich sehr leicht zu beheben ist.</dd>

<dt><code>wishlist</code></dt>
<dd>Für beliebige Feature-Requests, aber auch für beliebige Fehler, die
aufgrund wesentlicher konzeptioneller Erwägungen sehr schwer zu beheben
sind.</dd>
</dl>

<p>Bestimmte Schweregrade werden als
<em><a href="https://bugs.debian.org/release-critical/">\
veröffentlichungskritisch</a></em> 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 <strong>critical</strong>,
<strong>grave</strong> und <strong>serious</strong>. Die vollständigen
und kanonischen Regeln, welche Probleme diese Schweregrade
rechtfertigen, finden Sie in der Liste der
<a href="https://release.debian.org/testing/rc_policy.txt">veröffentlichungskritischen
Probleme für die stabile Veröffentlichung</a>.</p>


<h2><a name="tags">Markierungen für Fehlerberichte</a></h2>

<p>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.</p>

<p>Die Markierungen können durch das Einfügen einer <code>Tags</code>-Zeile in
   den
Pseudo-Kopfzeilen beim Abschicken des Fehlerberichts
(siehe <a href="Reporting#pseudoheader">Anweisungen für Fehlerberichte</a>),
oder durch das Benutzen des <code>tags</code>-Kommandos über den
<a href="#requestserv">Control Request Server</a> gesetzt werden.
Mehrere Markierungen können Sie durch Kommata, Leerzeichen oder beides 
trennen.</p>

<p>Die zurzeit verfügbaren Fehler-Markierungen sind: <bts_tags>.
   Hier sind ein paar zusätzliche Informationen über die Markierungen:
</p>

<dl>
<dt><code>patch</code></dt>
  <dd>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.</dd>

<dt><code>wontfix</code></dt>
  <dd>Dieser Fehler wird nicht behoben. Möglicherweise weil hier eine Wahl
  getroffen wurde zwischen zwei beliebigen Wegen, um bestimmte Dinge zu 
  erledigen und dabei stimmen der Paketbetreuer und der Absender des 
  Fehlerberichts in ihrer Meinung, wie diese Dinge erledigt werden sollten, 
  nicht überein, möglicherweise auch, weil die Änderung
  des Verhaltens andere, schlimmere Probleme nach sich ziehen würde
  oder aber auch aus anderen Gründen.</dd>

<dt><code>moreinfo</code></dt>
  <dd>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: <q>Das geht nicht</q>. Was geht
  nicht?</dd>

<dt><code>unreproducible</code></dt>
  <dd>Dieser Fehler kann nicht auf dem System des Paketbetreuers
  reproduziert werden. In diesem Fall wird die Hilfe einer Drittpartei
  bei der Diagnose der Ursachen des Problems benötigt.</dd>

<dt><code>help</code></dt>
  <dd>Der Paketbetreuer ersucht um Hilfe beim Beheben des Fehlers.
  Entweder hat der Betreuer nicht das nötige Wissen, um diesen Fehler
  zu beheben und wünscht die Mitarbeit durch andere, oder er ist überlastet
  und möchte diese Aufgabe deshalb an andere abgeben. Dieser Fehler
  könnte für Anfänger unpassend sein, außer er ist zusätzlich auch
  mit <code>newcomer</code> markiert.</dd>

<dt><code>newcomer</code></dt>
  <dd>Für diesen Fehler existiert eine bekannte Lösung, aber der
  Paketbetreuer ersucht darum, dass jemand anderes diese implementiert.
  Dies ist eine ideale Aufgabe für Anfänger, die sich in Debian
  einbringen oder die ihre Fähigkeiten verbessern wollen.</dd>

<dt><code>pending</code></dt>
  <dd>Eine Lösung für dieses Problem wurde gefunden und ein repariertes Paket
  wird bald hochgeladen.</dd>

<dt><code>fixed</code></dt>
  <dd>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. Diese Markierung ersetzt den
  alten Schweregrad <q>fixed</q>.</dd>

<dt><code>security</code></dt>
  <dd>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
  den Schweregrad <q>critical</q> oder <q>grave</q> gesetzt
  werden.</dd>

<dt><code>upstream</code></dt>
  <dd>Dieser Fehler bezieht sich auf Programm-Code des ursprünglichen
  Autors.</dd>

<dt><code>confirmed</code></dt>
  <dd>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.)</dd>

<dt><code>fixed-upstream</code></dt>
  <dd>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).</dd>

<dt><code>fixed-in-experimental</code></dt>
  <dd>Der Fehler wurde in dem Paket behoben, das in der
  Experimental-Distribution enthalten ist, aber noch nicht in der
  Unstable-Distribution.</dd>

<dt><code>d-i</code></dt>
  <dd>Dieser Fehler ist für die Entwicklung des debian-installers
  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.</dd>

<dt><code>ipv6</code></dt>
  <dd>Dieser Fehler beeinträchtigt die Unterstützung für das
  Internet-Protokoll Version 6.</dd>

<dt><code>lfs</code></dt>
  <dd>Dieser Fehler beeinträchtigt die Unterstützung großer Dateien
  (über 2 Gigabyte).</dd>

<dt><code>l10n</code></dt>
  <dd>Dieser Fehler ist für die Lokalisierung des Pakets relevant.</dd>

<dt><code>a11y</code></dt>
  <dd>Dieser Fehler ist bezüglich der Barrierefreiheit des Pakets relevant.</dd>

<dt><code>ftbfs</code></dt>
  <dd>Der Bau des Pakets aus dem Quellcode schlägt fehl. Wenn der Fehler einem
  Quellpaket zugewiesen ist, schlägt der Bau dieses Pakets fehl. Falls der
  Fehler einem Binärpaket zugewiesen ist, schlägt der Bau des dazugehörigen
  Quellpakets fehl. Diese Markierung kann auch für nicht-standardkonforme
  Build-Umgebungen angewandt werden (z.B. durch Verwendung von Build-Depends
  aus Experimental), allerdings sollte der Schweregrad in diesem Fall niedriger
  als serious sein (also: der Fehler ist nicht release-kritisch).</dd>

<dt><bts_release_tags></dt>
  <dd>Dies sind Release-abhängige Markierungen, die zwei verschiedene
      Auswirkungen haben: Wenn sie für einen Fehler gesetzt werden, ist
      dieser Fehler nur noch für die entsprechende Veröffentlichung relevant
      (obwohl es möglich ist, dass er auch andere Veröffentlichungen betrifft, 
      wenn deren Markierungen gesetzt sind), aber ansonsten gelten die normalen
      fehlerhaft/behoben/nicht-zutreffend-Regeln. Auch sollte dieser Fehler
      nicht archiviert werden, bis er in der entsprechenden Veröffentlichung
      behoben ist.</dd>
 
<dt><bts_release_ignore_tags></dt>
  <dd>Veröffentlichungskritische Fehler mit dieser Markierung sollen zum
      Zwecke der Veröffentlichung des entsprechenden Releases ignoriert werden.
      <strong>Diese Markierung sollte nur von Veröffentlichungsleitern verwendet
      werden; setzen Sie sie nicht selbst ohne deren ausdrückliche
      Berechtigung.</strong></dd>

</dl>

<p>Ein Wort über die Bedeutung von Distributions-spezifischen Markierungen:
   die <q>ignore</q>-Markierungen ignorieren
   Fehler zum Zweck des Übergangs nach Testing. Die
   Veröffentlichungs-Markierungen zeigen an, dass der betreffende Fehler
   noch nicht archiviert werden soll, bis er in den durch die Markierungen
   bezeichneten Veröffentlichungen behoben wurde. Außerdem zeigen die
   Veröffentlichungs-Markierungen an, dass ein Fehler nur in den
   entsprechenden Veröffentlichungen als Fehler betrachtet wird.
   [Mit anderen Worten ist der Fehler in jeder Veröffentlichung
   <strong>nicht vorhanden</strong>, deren korrespondierende Markierung
   <strong>nicht</strong> gesetzt ist, wenn überhaupt
   Veröffentlichungs-Markierungen gesetzt sind. Ansonsten gelten die
   normalen <q>found</q>- und <q>fixed</q>-Regeln.]
</p>

<p>
  Veröffentlichungs-Markierungen sollten <strong>nicht</strong>
  verwendet werden, wenn durch die korrekte Versionierung des Fehlers
  der gewünschte Effekt erreicht wird, weil sie manuell hinzugefügt
  und wieder gelöscht werden müssen. Wenn Sie unsicher sind, ob eine
  Veröffentlichungs-Markierung notwendig ist, wenden Sie sich an
  die Administratoren des Debian-Fehlerverwaltungssystems
  (<email "owner@bugs.debian.org">) oder an das Release-Team.
</p>


<h2><a name="forward">Aufzeichnen, dass Sie den Fehlerbericht weitergeleitet
  haben</a></h2>

<p>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:</p>

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

<p>Bitten Sie den Autor, das <code>CC</code> an
<var>nnn</var><code>-forwarded@bugs.debian.org</code> 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 <var>nnn</var><code>@bugs.debian.org</code>.</p>

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

<p>Sie können auch die <q>forwarded to</q>-Information manipulieren, indem
Sie eine Nachricht an <a href="server-control">\
<code>control@bugs.debian.org</code></a> schicken.</p>


<h2><a name="owner">Besitzer eines Fehlers ändern</a></h2>

<p>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.</p>

<p>Der Besitzer kann beim Senden eines Fehlerberichts durch eine
<code>Owner</code>-Zeile in den Pseudo-Kopfzeilen festgelegt werden
(siehe die <a href="Reporting#pseudoheader">Anweisungen über das Berichten
von Fehlern</a>) oder durch die Verwendung der Befehle
<code>owner</code> und <code>noowner</code> im Zusammenhang mit dem
<a href="#requestserv">Control Request Server</a>.</p>

<h2><a name="maintincorrect">Falsch angezeigte Paketbetreuer</a></h2>

<p>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 <code>Maintainer</code>-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 Pakets in nächster Zukunft nicht zu erwarten ist. Setzen Sie sich
mit <code>override-change@debian.org</code> in Verbindung, um
Änderungen an der override-Datei zu veranlassen.</p>


<h2><a name="requestserv">Wiedereröffnung, Neuzuweisung und Manipulation von
  Fehlerberichten</a></h2>

<p>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
<code>control@bugs.debian.org</code> senden.</p>

<p>Das <a href="server-control">Format dieser Nachrichten</a> ist in einem
anderen Dokument, das entweder im WWW oder in der Datei
<code>bug-maint-mailcontrol.txt</code> verfügbar ist, beschrieben. Eine
Volltextversion können Sie auch durch das Senden des Wortes
<code>help</code> an den oben genannten Server erhalten.</p>

<h2><a name="subscribe">Fehler abonnieren</a></h2>

<p>Die Fehlerdatenbank erlaubt denen, die Fehler berichten sowie Entwicklern
   und anderen
   interessierten dritten Parteien, individuelle Fehler zu abonnieren. Diese
   Fähigkeit kann von Leuten verwendet werden, die ein Auge auf einen Fehler
   halten wollen, ohne das gesamte Paket über den
   <a href="https://tracker.debian.org">Debian Package Tracker</a> zu abonnieren. Alle
   Nachrichten, die bei <var>nnn</var><code>@bugs.debian.org</code> empfangen werden,
   werden an die Abonnenten geschickt.</p>

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

<p>Es ist auch möglich, das Abonnement eines Fehlers zu beenden. Dies kann über
   eine E-Mail an <var>nnn</var><code>-unsubscribe@bugs.debian.org</code> 
   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, um das Abonnement des Fehlers zu beenden.</p>

<p>Standardmäßig wird die Adresse abonniert, die in der <code>From</code>-\
   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:
   <var>nnn</var><code>-subscribe-</code><var>Lokalteil</var><code>=</code><var>beispiel.com</var><code>@bugs.debian.org</code>.
   Dieses Beispiel würde <code>Lokalteil@beispiel.com</code> eine 
   Abonniermeldung für Fehler <var>nnn</var> schicken. Das 
   <code>@</code>-Zeichen muss durch Änderung in ein <code>=</code>-Zeichen 
   kodiert werden. Ähnlich nimmt die Beendigung des Abonnements die Form 
   <var>nnn</var><code>-unsubscribe-</code><var>Lokalteil</var><code>=</code><var>beispiel.com</var><code>@bugs.debian.org</code> 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.</p>


<h2><a name="subjectscan">Das mehr oder weniger veraltete
subject-scanning-Feature</a></h2>

<p>Nachrichten, die bei <code>submit</code> oder bei <code>bugs</code>
ankommen und deren Betreffzeile mit <code>Bug#</code><var>nnn</var>
anfängt, werden so behandelt, als wären sie an
<var>nnn</var><code>@bugs.debian.org</code> 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 <code>submit</code> geschickt wurden (z.B. durch das
Benutzen der <q>Allen antworten</q>-Funktion des jeweiligen
E-Mailprogramms).</p>

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

<p>Nachrichten, die nur mit <code>forwarded</code> und <code>done</code>
&ndash; das heißt ohne die Nummer des Fehlerberichts in der Adresse und ohne
Fehlernummer in der Betreffzeile &ndash; verschickt werden, werden unter
<q>junk</q> einsortiert und
für ein paar Wochen gespeichert, ansonsten jedoch ignoriert.</p>


<h2><a name="x-debian-pr">Das veraltete <code>X-Debian-PR:
  quiet</code>-Feature</a></h2>

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

<p>Diese Kopfzeile wird nun ignoriert. Stattdessen können Sie Ihre
Nachricht an <code>quiet</code> oder <var>nnn</var><code>-quiet</code>
(oder <code>maintonly</code> bzw. <var>nnn</var><code>-maintonly</code>)
schicken.</p>

<hr />

#use "otherpages.inc"

#use "$(ENGLISHDIR)/Bugs/footer.inc"