Dies ist eine leicht abgewandelte Kopie der online verfügbaren Anleitung des Subversion-Prokjekts für neue Benutzer, wie Fehler gemeldet werden sollten. Siehe im Kapitel , wo dargestellt wird, warum es wichtig ist, dass ein Projekt derartige Anleitungen hat. Das ursprüngliche Dokument befindet sich bei . 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.