Wie man ein Problem berichtet

Problembericht für ein Release

1. Prüfe zuerst die Patches und Hinweise für das Release.
2. Als nächstes prüfe, ob es ein neueres Release gibt.
3. Als letztes prüfe die Änderungen, die zwischen den OpenBSD-Releases gemacht wurden.

Wenn es anscheinend auf keiner der Seiten eine Lösung für dein Problem gibt, mach dich bitte mit sendbug(1) vertraut, bevor du einen Fehlerbericht einsendest.

Um herauszufinden, welche Fehlerberichttypen erwünscht sind, lies weiter unten.

Problembericht für current

1. teste das Problem mindestens zweimal mit Quelltexten, die im Abstand von mehreren Tagen aktualisiert wurden.
2. melde keine Kompilierungsprobleme im Sourcetree, es sei denn sie bleiben länger bestehen. Das sind meistens deine Fehler oder es wird bereits an ihnen gearbeitet, bevor du ihnen begegnest. Die Leute im Projekt machen mindestens einmal am Tag einen make build (normalerweise mehrmals am Tag) mit verschiedenen Architekturen.
3. denk daran, dass die anoncvs-Server mit deutlichem Zeitabstand zum eigentlichen Sourcetree aktualisiert werden.
4. prüfe ob dein Problem vielleicht mit den Änderungen zwischen den OpenBSD-Releases erledigt wurde.
5. Viel Aufwand wird bei der Erzeugung von Snapshots betrieben. Manchmal werden Fehler gemacht und unsere Entschuldigungen sind vielfältig. Es ist daher meist angebrachter, unsere Mailinglisten zu lesen und in einer davon über das Problem zu schreiben statt einen Problembericht zu senden.

Wie man einen Fehlerbericht schreibt

Bitte fang nicht an, Probleme zu beseitigen, die ein gewisses Maß an Arbeit benötigen, bis du absolut sicher bist, dass du sie auch verstehst; insbesondere während wir kurz vor der Veröffentlichung eines neuen Releases stehen und keine großen Teile unseres Quelltextes ändern können. Wenn du eine Menge Code schreibst, prüfe möglichst viele Foren, um zu prüfen, ob nicht bereits jemand anderes an dem Problem arbeitet.

Die folgenden Punkte sollten in jedem Fehlerbericht enthalten sein:

1. Die exakte Schrittabfolge von Anfang an, um das Problem zu reproduzieren. Sie sollte unbedingt vollständig sein: ein einfaches Kommando ohne die Argumente oder andere Daten reichen nicht aus. Wenn ein Fehler eine bestimmte Befehlsfolge erfordert, liste sie bitte auf. Selbstverständlich ist es gut, wenn du dein Beispiel möglichst klein hälst - wichtiger ist aber die Reproduzierbarkeit.

2. Die Ausgabe, die du erhältst. Sage bitte nicht so was wie "didn't work" oder "failed". Wenn es eine Fehlermeldung gibt, zeige sie, selbst wenn du sie nicht verstehst. Wenn OpenBSD mit einem bestimmten Fehler abstürzt, sag uns mit welchem. Wenn gar nichts passiert, sag das ebenfalls. Selbst wenn dein Problemfall ein Programm ist, das abstürzt oder etwas anderes Offensichtliches, muss das in unserer Umgebung nicht auftreten. Am einfachsten ist es, die Ausgabe - falls möglich - direkt von der Konsole zu kopieren.

   Hinweis: Im Falle fataler Fehler muss die ausgegebene Fehlermeldung nicht alle verfügbaren Informationen enthalten. In diesem Fall sieh dir auch die Ausgabe der Systemlogfiles an, die sich in /var/log befinden. Wenn du ein Problem mit einer Anwendung hast, die ihre eigene Logdatei schreibt (z. B. httpd), suche in der passenden Logdatei nach Fehlern (im Falle von httpd ist das /var/www/logs).

3. Die OpenBSD-Kernelausgabe. Die bekommst du mit dem dmesg-Befehl. Es ist aber möglich, dass deine dmesg-Ausgabe nicht alle Informationen bietet, die in /var/run/dmesg.boot zu finden sind. Wenn das der Fall ist, füge die Daten von Beiden hinzu. Bitte füge sie unbedingt zu allen Fehlerberichten hinzu.

4. Wenn du Software von Drittanbietern benutzt, die mit deinem Fehler zu tun hat, schreibe das auch, inklusive aller Versionsangaben, die deine Software bietet. Wenn du über einen CVS- oder FTP-Snapshot redest, erwähne das ebenso, einschließlich Datum und Uhrzeit.

5. Eine Rückverfolgung von deinem Systemabsturz. Wenn dein Kernel abstürzte und du an einem ddb>-Prompt bist, dann zeig uns deine Panicmessage genauso wie die Ausgabe der Befehle trace und ps in deinem Fehlerbericht.
   Sollte die Panicmessage aus irgendeinem Grund nicht sichtbar sein, kannst du sie erneut mit dem Befehl show panic bekommen.
   Das ist unbedingt notwendig. Panic-Berichte ohne die Panicmessage, traceback- und ps-Ausgaben sind sinnlos.
   Die Ausgabe von show registers könnte ebenso von Interesse sein. Du bootest dann am besten mit boot dump, so dass ein Kernelimage von savecore(8) gesichert werden kann, um weitere Informationen für unser »post mortem«-Debugging zu liefern.

6. Wenn du von einem Problem mit dem X Window System auf einer Plattform berichten willst, die auch den X.Org-Server nutzt, füge bitte die komplette /var/log/Xorg.0.log-Datei zusätzlich zu den Informationen aus dmesg.boot hinzu.

Mach dir keine Sorgen, wenn dein Fehlerbericht ziemlich lang wird. Das ist halt so - und viel besser, als dass wir dir jede Information aus der Nase ziehen müssen. Andererseits ist es natürlich auch fair vorher zu fragen, ob sich jemand deinen Fehlerbericht ansehen will.

Und zuletzt solltest du beim Schreiben eines Fehlerberichts unbedingt unmissverständliche Worte wählen.

Einsenden eines Fehlerberichts

Wenn irgendwie möglich, benutze das Kommando sendbug(1), um den Fehlerbericht in unser Trackingsystem zu bekommen. Du kannst dem Trackingsystem auf dieser Webseite folgen. Damit du sendbug verwenden kannst, muss dein System wenigstens zeitweise über das Internet E-Mails versenden können. Wenn du sendbug nicht auf einer funktionierenden OpenBSD-Maschine nutzen kannst, sende deinen Fehlerbericht bitte an bugs@openbsd.org.

Es kann aber auch passieren, dass du keinen Fehlerbericht sendest, sondern eine Anfrage nach einer neuen Funktionalität. Diese werden akzeptiert, insbesondere mit Quelltext, der deine neuen vorgeschlagenen Funktionalitäten implementiert. Wenn jemand anderes den Quelltext für deinen Vorschlag schreibt, kann es gut passieren, dass dabei irgendein Missverständnis auftritt und du das gar nicht bemerkst.

Zum Debuggen einiger Probleme müssen wir die Hardware passend zum Problem haben. Bitte bedenke, dass die Ressourcen des OpenBSD-Projekts begrenzt sind. Du könntest Hardware spenden.

Arten von Fehlerberichten in absteigender Beliebtheitsreihenfolge:

1. Reproduzierbare Probleme mit Quelltextkorrekturen sind die besten.
2. Reproduzierbare Probleme, die nicht von deinem Hardware/Softwarelayout abhängig sind.
3. Reproduzierbare Probleme, die spezifisch für dein Softwarelayout sind.
4. Reproduzierbare Probleme, die spezifisch für dein Hardwarelayout sind.
5. Nicht reproduzierbare Probleme - oder Probleme die du nicht erneut hervorrufen willst.