<p>Da es für die Haiku-Entwickler unmöglich ist, jede denkbare Hardware-Kombination oder jede mögliche Anwendungsweise eines Programmes zu testen, ist es eine große Hilfe, wenn erkannte Fehler von Anwendern gemeldet werden. Da Haiku noch nicht vollständig ausgereift ist - aktuell befindet es sich in der Alpha-Phase - ist es nicht unwahrscheinlich, dass Fehler auftreten. Nur mit Hilfe der Anwender können wir Haiku Stück für Stück perfektionieren.</p>
<p>Um unseren "Bugtracker" - also die Liste aller gefundenen Fehler - effektiv zu halten, ist es notwendig, eine grundlegende Etikette, die "<ahref="http://dev.haiku-os.org/wiki/BugTrackerEtiquette">Bug Tracker Etiquette</a>" zu wahren.</p>
<h2>Wie man einen Zugang zum Trac erhält</h2>
<p>Um ein Fehler-Ticket einzureichen, muss man registrierter Benutzer beim <ahref="http://dev.haiku-os.org/register"title="Register at Haiku's Bugtracker">Bugtracker</a> sein.<br/> Um sich anzumelden ist eine <b>gültige E-Mail Adresse</b> notwendig. Sollte nach dem Anmelden keine Bestätigungsmail erhalten werden, lohnt es sich, seinen <b>Spam-Filter</b> zu überprüfen.</p>
<h2>Einen Fehlerbericht erstellen</h2>
<p>Ehe man einen Fehler meldet, sollte man sich <ahref="http://dev.haiku-os.org/query?status=new&status=assigned&status=reopened&status=closed&summary=%7Etext+you+want+to+search+for&order=priority">sicher sein</a>, dass er nicht schon gemeldet wurde. Hierzu kann auch die <ahref="http://dev.haiku-os.org/search?q=&noquickjump=1&ticket=on">Suchfunktion</a> verwendet werden.<br/>
Nach dieser Überprüfung sollte man so genau wie möglich den Fehler beschreiben:</p>
<ul>
<li><p>Wie wurde Haiku verwendet (auf echter Hardware oder virtualisiert unter VMWare, QEMU oder ähnlichem)</p></li>
<li><p>Welche Versionsnummer des <acronymtitle="Subversion, the source code management system we use">SVN</acronym> wurde verwendet?. Die Nummer ist auch unter '<i>About This System...</i>' im Deskbar-Menü abzulesen.</p></li>
<li><p>Der Fehler sollte so präzise wie möglich beschrieben werden. Wie war das tatsächliche Verhalten im Gegensatz zum Erwarteten?</p></li>
<li><p>Wann ist der Fehler aufgetreten? Welche Schritte führten dazu? Nur so können die Entwickler den Fehler nachstellen und erkennen.</p></li>
<li><p>An den Fehlerbericht sollten so viele Informationen wie möglich angehängt werden. Log-Dateien oder Bildschirmphotos (die Taste <spanclass="key">PRINT</span> speichert den Bildschirm als <acronymtitle="Portable Network Graphics image format">PNG</acronym> im Verzeichnis <spanclass="path">/boot/home/</span>) sind sehr hilfreich.</p></li>
</ul>
<h3>Fehler in Anwendungen</h3>
<p>Wenn eine Anwendung unerwartet abstürzt, sollte man den "Debugger" aus dem erscheinenden Hinweisfenster aufrufen. Ein <spanclass="cli">bt</span> im daraufhin startenden Terminal erstellt einen sogenannten "backtrace" der mit an die Fehlermeldung angehängt werden sollte.</p>
<h3>Fehler auf Grund Hardware</h3>
<p>Wenn ein Fehler gemeldet wird, der Hardware oder Treiber betrifft, sollten mindestens diese Informationen an den Fehlerbericht angehängt werden:</p>
<ul>
<li><spanclass="cli">listdev</span> - eine detaillierte Auflistung aller vorhandener Hardware inklusive "vendor id" und "pci id"; ähnlich den Befehlen <spanclass="cli">lshw</span> und <spanclass="cli">lspci</span> unter Linux.</li>
<li><spanclass="cli">listusb -v</span> - bei einem Fehler im Zusammenhang mit USB; ähnlich dem Befehlt <spanclass="cli">lsusb</span>.</li>
<li><spanclass="cli">open /var/log/syslog</span> - die zentrale Log-Datei in Haiku. Mit dem Befehl <spanclass="cli">open</span> kann das Log auf eine sinnvolle Länge gekürzt werden.</li>
<li><spanclass="cli">listimage | grep drivers/</span> - eine Auflistung aller verwendeter Treiber.</li>
<li><spanclass="cli">ints</span> - nur im <i>Kernel Debugging Land</i> (siehe weiter unten) möglich. Es zeigt eine Liste aller verwendeter "Interrupts".</li>
</ul>
<p>Die genannten Befehle sind im Terminal einzugeben. Mit dem Anhang "<spanclass="cli">> output.txt</span>" an den Befehl wird dessen Ausgabe in die Datei output.txt gespeichert, die dann an den Fehlerbericht angehängt werden kann.</p>
<h3>Kernel Debugging Land - KDL</h3>
<p>Wenn grundlegende Systemkomponenten abgestürzt sind, dann friert das System ein und es wird das KDL aufgerufen. Man kann auch absichtlich dorthin wechseln durch Drücken von <spanclass="key">ALT</span><spanclass="key">SysReq</span><spanclass="key">D</span> (<spanclass="key">SysReq</span> ist in den meisten Fällen die Taste <spanclass="key">PRINT</span>).</p>
<ul>
<li><spanclass="cli">co</span> - beendet das KDL und das System läuft - soweit möglich - normal weiter.</li>
<li><spanclass="cli">int</span> - zeigt die verwendeten Interrupts (wie oben beschrieben).</li>
<li><spanclass="cli">bt</span> - zeigt einen backtrace wo genau der Fehler aufgetreten ist.</li>
</ul>
<h2>Fehler gemeldet, und dann?</h2>
<p>Nachdem ein Fehler gemeldet wurde wird sich ein Entwickler ihm annehmen und bewerten. Da es sich bei allen Entwicklern um Freiwillige handelt, die in ihrer Freizeit programmieren, kann es durchaus etwas dauern, bis man eine Rückmeldung erhält. Je mehr Informationen man einer Fehlermeldung beifügt oder nachreicht, um so leichter ist es für den Programmierer, diesen zu beheben.</p>
<p>Wenn man einen Fehler gemeldet hat ist es damit nicht abgeschlossen, eigentlich ist es erst der Anfang und man wird Teil des Entwicklungs-Prozesses von Haiku. Es ist durchaus möglich und eigentlich auch zu erwarten, dass sich ein Entwickler meldet, um näheres zu den Umständen des Fehler-Reports zu erfahren. Hier gilt wieder: je mehr man dem Entwickler helfen kann, um so leichter tut er sich mit der Fehlerbehebung. Erst wenn der Fehler als 'fixed' - also behoben - markiert ist, kann man sich zurücklehnen, mit dem guten Gefühl etwas beigetragen zu haben.</p>
