Author: mbarkhau Date: Sun Jul 29 09:34:15 2007 New Revision: 861 Log: Finished appd
Modified: trunk/de/appd.xml Modified: trunk/de/appd.xml ============================================================================== --- trunk/de/appd.xml (original) +++ trunk/de/appd.xml Sun Jul 29 09:34:15 2007 @@ -1,111 +1,136 @@ <appendix id="bug-reporting"> -<title>Example Instructions for Reporting Bugs</title> +<title>Beispiel Anleitung für die Meldung von Fehlern</title> <simplesect> - -<para>This is a lightly-edited copy of the Subversion project's online -instructions to new users on how to report bugs. See -<xref linkend="users-to-volunteers"/><phrase output="printed"> in -<xref linkend="managing-volunteers"/></phrase> for why it is -important that a project have such instructions. The original -document is located at -<ulink url="http://svn.collab.net/repos/svn/trunk/www/bugs.html"/>.</para> +# vim: tw=72 +<para>Dies ist eine leicht bearbetete Kopie der online verfügbaren +Anleitung des Subversion Prokjekts, an neue Benutzer darüber wie Fehler +gemeldet werden sollen. Siehe <xref +linkend="users-to-volunteers"/><phrase output="printed"> im Kapitel +<xref linkend="managing-volunteers"/></phrase> welches behandelt, warum +es wichtig ist, dass ein Projek solche Anleitungen hat. Das +ursprüngliche Dokument befindet sich bei <ulink +url="http://svn.collab.net/repos/svn/trunk/www/bugs.html"/>.</para> <screen> - Reporting Bugs in Subversion + Meldung von Fehlern in Subversion -This document tells how and where to report bugs. (It is not a list of -all outstanding bugs — you can get that here instead.) +Dieses Dokument handelt darüber wie und wo Fehler gemeldet werden +sollen. (Es ist keine Liste aller noch bestehender Fehler — welches Sie +statt dessen hier bekommen können.) -Where To Report A Bug +Wo man einen Fehler melden soll. --------------------- - * If the bug is in Subversion itself, send mail to - [EMAIL PROTECTED] Once it's confirmed as a bug, - someone, possibly you, can enter it into the issue tracker. (Or - if you're pretty sure about the bug, go ahead and post directly - to our development list, [EMAIL PROTECTED] But if - you're not sure, it's better to post to users@ first; someone - there can tell you whether the behavior you encountered is - expected or not.) - - * If the bug is in the APR library, please report it to both of - these mailing lists: [EMAIL PROTECTED], [EMAIL PROTECTED] - - * If the bug is in the Neon HTTP library, please report it to: - [EMAIL PROTECTED], [EMAIL PROTECTED] - - * If the bug is in Apache HTTPD 2.0, please report it to both of - these mailing lists: [EMAIL PROTECTED], - [EMAIL PROTECTED] The Apache httpd developer mailing - list is high-traffic, so your bug report post has the - possibility to be overlooked. You may also file a bug report at - http://httpd.apache.org/bug_report.html. + * Wenn der Fehler in Subversion selber ist, senden Sie eine Email an + [EMAIL PROTECTED] Sobalt es als Fehler bestätigt wird, + kann jemand, vielleicht du, es in das Ticket System eingeben. + (Oder wenn Sie sich ziemlich sicher darüber sind, können Sie auch + gleich an unseren Entwickler Verteiler schreiben, + [EMAIL PROTECTED] Wenn du dir aber nicht sicher bits, ist + es besser wenn du zuerst an users@ schreibst; dort kann dir jemand + sagen, ob das Verhalten, dass du beobachtet hast richtig ist oder + nicht.) + + * Wenn der Fehler in der APR Bibliothek ist, melde es bitte bei + einem dieser Verteiler: [EMAIL PROTECTED], + [EMAIL PROTECTED] + + * Wenn der Fehler in der Neon HTTP Bibliothek ist, melde es bitte + bei: [EMAIL PROTECTED], [EMAIL PROTECTED] + + * Wenn der Fehler in Apache HTTPD 2.0 ist, melde es bitte an beide + der folgenden Verteiler: [EMAIL PROTECTED], + [EMAIL PROTECTED] Der Apache httpd Entwickler Verteiler + hat einen hohen Betrieb, es ist also möglich, dass deine Meldung + übersehen wird. Du kannst auch eine Bug Meldung bei + http://httpd.apache.org/bug_report.html einreichen. * If the bug is in your rug, please give it a hug and keep it snug. -How To Report A Bug +<!-- +Rhymes are always tough: +* Wenn die Laus bei der Maus ist, wirf's aus dem Haus mit raus. + +(alternativly starting differently, which would only require +adaptions of the previous four entries, i.e. + Ist der Fehler in der Apache.... + Liegt der Fehler bei der Apache... + +* Ist die Laus bei der Maus, wirf's aus dem Haus mit raus. +* Wenn dein Fehler beim Heler ist, meld es eher beim Richter. +--> + +Wie man einen Bug meldet ------------------- -First, make sure it's a bug. If Subversion does not behave the way you -expect, look in the documentation and mailing list archives for -evidence that it should behave the way you expect. Of course, if it's -a common-sense thing, like Subversion just destroyed your data and -caused smoke to pour out of your monitor, then you can trust your -judgement. But if you're not sure, go ahead and ask on the users -mailing list first, [EMAIL PROTECTED], or ask in IRC, -irc.freenode.net, channel #svn. - -Once you've established that it's a bug, the most important thing you -can do is come up with a simple description and reproduction -recipe. For example, if the bug, as you initially found it, involves -five files over ten commits, try to make it happen with just one file -and one commit. The simpler the reproduction recipe, the more likely a -developer is to successfully reproduce the bug and fix it. - -When you write up the reproduction recipe, don't just write a prose -description of what you did to make the bug happen. Instead, give a -literal transcript of the exact series of commands you ran, and their -output. Use cut-and-paste to do this. If there are files involved, be -sure to include the names of the files, and even their content if you -think it might be relevant. The very best thing is to package your -reproduction recipe as a script, that helps us a lot. - -<emphasis>Quick sanity check: you *are* running the most recent version of -Subversion, right? :-) Possibly the bug has already been fixed; you -should test your reproduction recipe against the most recent -Subversion development tree.</emphasis> - -In addition to the reproduction recipe, we'll also need a complete -description of the environment in which you reproduced the bug. That -means: - - * Your operating system - * The release and/or revision of Subversion - * The compiler and configuration options you built Subversion with - * Any private modifications you made to your Subversion - * The version of Berkeley DB you're running Subversion with, if any - * Anything else that could possibly be relevant. Err on the side - of too much information, rather than too little. - -Once you have all this, you're ready to write the report. Start out -with a clear description of what the bug is. That is, say how you -expected Subversion to behave, and contrast that with how it actually -behaved. While the bug may seem obvious to you, it may not be so -obvious to someone else, so it's best to avoid a guessing game. Follow -that with the environment description, and the reproduction recipe. If -you also want to include speculation as to the cause, and even a patch -to fix the bug, that's great — see -http://svn.collab.net/repos/svn/trunk/www/hacking.html#patches for -instructions on sending patches. - -Post all of this information to [EMAIL PROTECTED], or if you -have already been there and been asked to file an issue, then go to -the Issue Tracker and follow the instructions there. - -Thanks. We know it's a lot of work to file an effective bug report, -but a good report can save hours of a developer's time, and make the -bug much more likely to get fixed. +Vergewissere dich erst, dass es ein Fehler ist. Wenn Subversion sich +nicht so verhällt wie du es erwartest, schaue in der Dokumentation und +den Archiven der Email Verteiler nach beweisen, dass es sich so +verhalten sollte wie du es erwartest. Wenn es natürlich etwas +offensichtliches ist, wie wenn Subversion eben deine Daten zerstört hat +und deine Bildschirm dazu gebracht hat Rauch auszuspucken, dann kannst +du deinem Urteil vertrauen. Wenn du dir aber nicht sicher bist, frage +lieber zuerst bei dem Email Verteiler für Nutzer nach, [EMAIL PROTECTED], oder frage im IRC bei #svn auf +irc.freenode.net nach. + +Wenn dir dann sicher bist, dass es ein Fehler ist, ist das wichtigste +was du machen kannst, dir eine einfache Beschreibung und eine Anleitung +wie der Fehler reproduziert weden kann auszudenken. Wenn der Fehler als +du ihn ursprünglich gefunden hast, fünf Dateien über zehl Commits +brauchte, versuche es mit nur einer Datei und einem Commit zu +verursachen. Je einfacher die Anleitung, desto wahrscheinlicher wird ein +Entwickler es erfolgreich reproduzieren und beheben können. + +Wenn du die Anleitung schreibst, erkläre nicht einfach in Worten, was du +gemacht hats um den Fehler zu bekommen. Schreibe statt dessen ein +genaues Protokoll, welche Befehle du eingegeben hast und was sie +ausgegeben haben. Du solltes das über Kopieren und einfügen machen. Wenn +Dateien dafür gebraucht werden, solltest du die Namen der Dateien +angeben, und sogar ihren Inhalt, wenn du meist die wäre relevant. Am +besten ist es, wenn du deine Anleitung als Skript zusammenschnürst, das +hilft ungemein. + +<emphasis>Nur kurz um etwas aus dem Weg zu räumen: Du *hast* doch die +neuste Version, oder? :-) Der Fehler wurde vielleicht schon behoben; du +solltest deine Anleitung bei der aktuellen Entwickler Version von +Subversion ausprobieren.</emphasis> + +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: + + * Dein Betriebssystem + * Die Version und/oder Revision von Subversion + * Der Compiler und die Einstellungen die du benutzt hast um dein + Build von Subversion zu machen. + * Irgend welche Änderungen an Subversion die du vorgenommen hast. + * Die Version von Berkeley DB die du mit Subversion benutzt, wenn + überhaupt + * Alles andere, was möglicherweise relevant sein könnte. Wobei du + lieber zuviel Informationen geben solltest, als zu wenige. + +Wenn du das alles gemacht hast, bist du bereit die Meldung zu schreiben. +Fange mit einer Klaren beschreibung des Fehlers an. D.h. sage, wie du +erwartest, dass sich Subversion verhalten sollte, und im Gegensatz dazu +wie es sich wirklich verhalten hat. Auch wenn der Fehler dir +offensichtlich erscheint, muss es das nicht unbeningt für jemand anderes +sein, es ist also am besten ein Ratespiel zu vermeiden. Danach solltest +du die Beschreibung der Umgebung und die Anleitung angeben. Wenn du auch +eine Spekulation über die Ursache machen willst, und sogar einen Patch +um den Fehler zu beheben, wäre das Super — siehe +http://svn.collab.net/repos/svn/trunk/www/hacking.html#patches für eine +Anleitung, darüber wie Patches eingereicht werden sollten. + +Schreibe all diese Informationen an [EMAIL PROTECTED], oder wenn +du bereits dort gewesen bist und darum gebeten wurdest einen Ticket auf +zu machen, gehe direkt zu den Ticket Tracker und folge dort der +Anleitung. + +Danke. Wir wissen, dass es eine Menge Arbeit ist eine effektive Bug +Meldung zu schreiben, eine gute Meldung kan aber Stunden Arbeit für +einen Entwickler sparen, und der Fehler wird viel eher behoben. </screen> </simplesect> _______________________________________________ Producingoss-translators mailing list [email protected] http://www.red-bean.com/mailman/listinfo/producingoss-translators
