Dies ist eine leicht abgewandelte Kopie der online verfügbaren Anleitung des Subversion-Prokjekts für neue Benutzer, wie Fehler gemeldet werden sollten. Siehe „Behandeln Sie jeden Nutzer wie einen möglichen Freiwilligen“ im Kapitel Kapitel 8, Leitung von Freiwilligen, wo dargestellt wird, warum es wichtig ist, dass ein Projekt derartige Anleitungen hat. Das ursprüngliche Dokument befindet sich bei http://svn.collab.net/repos/svn/trunk/www/bugs.html.
So melden Sie Fehler in Subversion
Dieses Dokument erläutert, wie und wo Fehler Sie Fehler melden sollten.
(Es ist keine Liste aller noch bestehender Fehler — diese können Sie
stattdessen hier bekommen.)
Wo Sie einen Fehler melden sollten
----------------------------------
* Liegt der Fehler in Subversion selbst, senden Sie eine E-Mail
an users@subversion.tigris.org. Sobald der Fehler bestätigt wird,
kann jemand, vielleicht Sie, ihn in das Ticketsystem eingeben.
(Oder wenn Sie sich ziemlich sicher sind, können Sie auch
gleich an unsere Entwickler-Liste schreiben,
dev@subversion.tigris.org. Sind Sie sich aber nicht sicher, ist
es besser zuerst an users@ zu schreiben; dort kann Ihnen
jemand sagen, ob das Verhalten, das Sie beobachtet haben,
beabsichtigt ist oder nicht.)
* Liegt der Fehler in der APR-Bibliothek, melden Sie dies
bitte auf einer dieser Mailinglisten: dev@apr.apache.org,
dev@subversion.tigris.org.
* Liegt der Fehler in der Neon-HTTP-Bibliothek, melden Sie
dies bitte bei: neon@webdav.org, dev@subversion.tigris.org.
* Liegt der Fehler in Apache-HTTPD 2.0, melden Sie dies
bitte an die beiden folgenden Mailinglisten: dev@httpd.apache.org,
dev@subversion.tigris.org. Auf der Mailingliste der
Apache-httpd-Entwickler herrscht Hochbetrieb, es ist also möglich,
dass Ihre Meldung übersehen wird. Sie können auch eine Bug-Meldung
unter http://httpd.apache.org/bug_report.html einreichen.
* If the bug is in your rug, please give it a hug and keep it snug.
Wie Sie einen Bug melden sollten
--------------------------------
Vergewissern Sie sich erst, dass es ein Fehler ist. Wenn Subversion sich
nicht so verhält wie Sie es erwarten, schauen Sie in der Dokumentation und
den Archiven der Mailverteiler nach und weisen Sie nach, dass es sich so
verhalten sollte, wie Sie es erwarten. Wenn es allerdings etwas
Offensichtliches ist, wie wenn Subversion mal eben Ihre Daten zerstört
und Ihren Bildschirm dazu bringt, Rauch auszuspucken, dann können
Sie Ihrem Urteil vertrauen. Wenn Sie sich aber nicht sicher sind, fragen
Sie lieber zuerst auf der Benutzer-Mailingliste (users@subversion.tigris.org)
oder im IRC bei #svn auf irc.freenode.net nach.
Wenn Sie sich dann sicher sind, dass es ein Fehler ist, ist es das
wichtigste, eine einfache Beschreibung und eine Anleitung zu finden,
nach der der Fehler reproduziert weden kann. Wenn der Fehler als
Sie ihn ursprünglich gefunden haben, fünf Dateien über zehn Commits
brauchte, versuchen Sie ihn mit nur einer Datei und einem Commit
auszulösen. Je einfacher die Anleitung, desto wahrscheinlicher wird ein
Entwickler ihn erfolgreich reproduzieren und beheben können.
Wenn Sie die Anleitung schreiben, erklären Sie nicht einfach in Worten,
was Sie gemacht haben, um den Fehler zu bekommen. Schreiben Sie
stattdessen ein genaues Protokoll, welche Befehle Sie eingegeben haben
und was diese ausgegeben haben. Sie sollten dies über Kopieren und
Einfügen tun. Wenn Dateien dafür gebraucht werden, sollten Sie die Namen
der Dateien angeben, und sogar ihren Inhalt, wenn Sie meinen, dass diese
relevant wären. Am besten ist es, wenn Sie Ihre Anleitung in Form eines
Skripts bündeln würden, so etwas hilft ungemein.
Nur kurz um etwas aus dem Weg zu räumen: Sie *haben* doch die
neuste Version, oder? :-) Der Fehler wurde vielleicht schon behoben; Sie
sollten deshalb Ihre Anleitung mit der aktuellen Entwickler-Version von
Subversion ausprobieren.
Zusätzlich zu der Anleitung für die Reproduktion, brauchen wir auch eine
komplette Beschreibung der Umgebung in der du den Fehler reproduziert
hast. Das heißt:
* Ihr Betriebssystem
* Die Version und/oder Revision von Subversion
* Der Compiler und die Einstellungen die Sie benutzt haben um Ihr
Build von Subversion zu erstellen
* Etwaige Änderungen, die Sie an Subversion vorgenommen haben
* Die Version von Berkeley DB die Sie mit Subversion benutzen,
falls überhaupt
* Alles andere, was möglicherweise relevant sein könnte. Wobei
Sie lieber zuviel Informationen geben sollten, als zu wenig.
Wenn Sie all dies gemacht haben, sind Sie bereit die Meldung zu schreiben.
Fangen Sie mit einer klaren Beschreibung des Fehlers an. D.h. sagen Sie,
wie Sie erwarten, dass sich Subversion verhalten sollte, und im Gegensatz
dazu wie es sich wirklich verhalten hat. Auch wenn der Fehler Ihnen
offensichtlich erscheint, muss das nicht unbeningt für jemand anderes
gelten, also vermeiden Sie am besten Ratespiele. Danach sollten Sie
sich der Beschreibung der Umgebung zuwenden und der Anleitung zur
Reproduktion des Fehlers. Wenn Sie auch eine Spekulation über die Ursache
anstellen wollen, oder sogar einen Patch anbieten können, um den Fehler zu
beheben, wäre das super — siehe
http://subversion.apache.org/docs/community-guide/#patches für eine
Anleitung, wie Patches eingereicht werden sollten.
Schreiben Sie all diese Informationen an dev@subversion.tigris.org, oder
wenn Sie bereits dort gewesen sind und darum gebeten wurden ein Ticket
anzulegen, gehen Sie direkt zum Bugtracker und folgen der dortigen
Anleitung.
Danke. Wir wissen, dass es eine Menge Arbeit ist, eine effektive
Bug-Meldung zu schreiben, aber eine gute Meldung kann einem Entwickler
Stunden der Arbeit ersparen, und der Fehler wird so viel eher behoben.