mirror of
https://review.haiku-os.org/userguide
synced 2024-11-23 15:18:25 +01:00
189 lines
21 KiB
HTML
189 lines
21 KiB
HTML
<?xml version="1.0" encoding="UTF-8"?>
|
||
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
|
||
<html xmlns="http://www.w3.org/1999/xhtml" lang="de" xml:lang="de">
|
||
<head>
|
||
<!--
|
||
*
|
||
* Copyright 2008-2020, Haiku. All rights reserved.
|
||
* Distributed under the terms of the MIT License.
|
||
*
|
||
* Authors:
|
||
* Niels Reedijk, Matt Madia and Ingo Weinhold who wrote
|
||
* http://dev.haiku-os.org/wiki/ and http://dev.haiku-os.org/wiki/ReportingBugs
|
||
* Humdinger <humdingerb@gmail.com>
|
||
* Translators:
|
||
* FabianR
|
||
* Humdinger
|
||
* Matthias
|
||
* taos
|
||
*
|
||
-->
|
||
<meta http-equiv="content-type" content="text/html; charset=utf-8" />
|
||
<meta name="robots" content="all" />
|
||
<title>Bugs melden</title>
|
||
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
|
||
<link rel="stylesheet" type="text/css" href="../Haiku-doc.css" />
|
||
</head>
|
||
<body>
|
||
|
||
<div id="banner">
|
||
<div><span>User Guide</span></div>
|
||
</div>
|
||
|
||
<div class="nav">
|
||
<div class="inner">
|
||
<ul class="lang-menu">
|
||
<li class="now">Deutsch <span class="dropdown-caret">▼</span></li>
|
||
<li><a href="../id/bugreports.html">Bahasa Indonesia</a></li>
|
||
<li><a href="../ca/bugreports.html">Català</a></li>
|
||
<li><a href="../en/bugreports.html">English</a></li>
|
||
<li><a href="../es/bugreports.html">Español</a></li>
|
||
<li><a href="../eo/bugreports.html">Esperanto</a></li>
|
||
<li><a href="../fr/bugreports.html">Français</a></li>
|
||
<li><a href="../fur/bugreports.html">Furlan</a></li>
|
||
<li><a href="../it/bugreports.html">Italiano</a></li>
|
||
<li><a href="../hu/bugreports.html">Magyar</a></li>
|
||
<li><a href="../pl/bugreports.html">Polski</a></li>
|
||
<li><a href="../pt_PT/bugreports.html">Português</a></li>
|
||
<li><a href="../pt_BR/bugreports.html">Português (Brazil)</a></li>
|
||
<li><a href="../ro/bugreports.html">Română</a></li>
|
||
<li><a href="../sk/bugreports.html">Slovenčina</a></li>
|
||
<li><a href="../fi/bugreports.html">Suomi</a></li>
|
||
<li><a href="../sv_SE/bugreports.html">Svenska</a></li>
|
||
<li><a href="../tr/bugreports.html">Türkçe</a></li>
|
||
<li><a href="../zh_CN/bugreports.html"> 中文 ［中文］</a></li>
|
||
<li><a href="../ru/bugreports.html">Русский</a></li>
|
||
<li><a href="../uk/bugreports.html">Українська</a></li>
|
||
<li><a href="../jp/bugreports.html">日本語</a></li>
|
||
</ul>
|
||
<span>
|
||
<a href="../welcome_de.html" class="uplink">Welcome</a>
|
||
</span></div>
|
||
</div>
|
||
|
||
<div id="content">
|
||
<div>
|
||
|
||
<table class="index" id="index" summary="index">
|
||
<tr class="heading"><td>Index</td></tr>
|
||
<tr class="index"><td><a href="#account">Zugang zu Trac</a><br />
|
||
<a href="#report">Bugreport erstellen</a><br />
|
||
<a href="#app">Bugs in Anwendungen</a><br />
|
||
<a href="#server">Bugs in Servern</a><br />
|
||
<a href="#kernel">Bugs im Kernel</a><br />
|
||
<a href="#kdl">Kernel Debugging Land - KDL</a><br />
|
||
<a href="#syslog">Syslog</a><br />
|
||
<a href="#onscreen">Debug Ausgabe auf dem Bildschirm</a><br />
|
||
<a href="#hardware">Bugs von Hardware/Treiber</a><br />
|
||
<a href="#next">Bug gemeldet, und dann?</a></td></tr>
|
||
</table>
|
||
|
||
<h1>Bugs melden</h1>
|
||
|
||
<p>Da es für die Haiku-Entwickler unmöglich ist, jede denkbare Hardware-Kombination oder jede mögliche Anwendungsweise eines Programms zu testen, ist es eine große Hilfe, wenn Fehler gemeldet werden. Da Haiku noch recht jung ist, sind Bugs nicht ungewöhnlich. Wir sind dankbar für die Zeit, die Sie sich nehmen, um Fehler zu melden. Nur mit Hilfe der Anwender können wir Haiku Stück für Stück verbessern.</p>
|
||
<p>Damit unser "Bugtracker" - also die Liste aller gefundenen Fehler - effektiv funktioniert, ist es von grundlegender Bedeutung, sich an die <a href="http://dev.haiku-os.org/wiki/BugTrackerEtiquette">Bug Tracker Etiquette</a> zu halten.</p>
|
||
|
||
<h2><a href="#"><img src="../images/up.png" style="border:none;float:right" alt="index" /></a>
|
||
<a id="account" name="accout">Zugang zu Trac</a></h2>
|
||
<p>Um ein Fehler-Ticket aufzugeben, muss man sich beim <a href="http://dev.haiku-os.org/register" title="Registerierung bei Haikus Bugtracker">Bugtracker</a> registrieren.<br /> Dafür ist eine <b>gültige E-Mail Adresse</b> notwendig. Sollte nach dem Registrieren keine Bestätigungsmail ankommen, sollte man mal seinen <b>Spam-Ordner</b> überprüfen.</p>
|
||
|
||
<h2><a href="#"><img src="../images/up.png" style="border:none;float:right" alt="index" /></a>
|
||
<a id="report" name="report">Bugreport erstellen</a></h2>
|
||
<p>Bevor man einen Fehler meldet, sollte man sich <a href="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 das nicht schon geschehen ist. Hierzu nutzt man die <a href="http://dev.haiku-os.org/search?q=&noquickjump=1&ticket=on">Suchfunktion</a>.<br />
|
||
Nach dieser Überprüfung sollte man so genau wie möglich den Fehler beschreiben:</p>
|
||
<ul>
|
||
<li><p>Der Fehler sollte mit einer aktuellen Version von Haiku reproduzierbar sein. Zum Testen gibt es installierbare <a href="http://download.haiku-os.org">Nightly Images</a>.</p></li>
|
||
<li><p>Wie wurde Haiku verwendet (auf echter Hardware oder virtualisiert unter VMWare, QEMU oder ähnlichem)?</p></li>
|
||
<li><p>Welche Haiku-Versionsnummer wurde verwendet? Die Version ist unter <span class="menu">Über Haiku...</span> im Deskbar Menü zu finden. Wie genau Haiku kompiliert wurde (x86_gcc2, x86_64), ist ebenfalls von Interesse. Die runterladbaren Images sind entsprechend benannt. Bei selbst gebauten Haiku-Images, sollte man wissen, wie das gemacht wurde.</p></li>
|
||
<li><p>Der Fehler sollte so präzise wie möglich beschrieben werden. Welches Verhalten wurde erwartet und was wurde stattdessen beobachtet?</p></li>
|
||
<li><p>Wann tritt der Fehler auf? Nur mit einer Schritt-für-Schritt Anleitung können die Entwickler den Bug nachstellen und beheben.</p></li>
|
||
<li><p>An den Fehlerbericht sollten so viele Informationen wie möglich angehängt werden. Handelt es sich um einen Bug in der grafischen Oberfläche oder einer der Anwendungen, ist ein Bildschirmfoto mittels der <span class="key">DRUCK</span> Taste hilfreich.</p></li>
|
||
</ul>
|
||
|
||
<h2><a href="#"><img src="../images/up.png" style="border:none;float:right" alt="index" /></a>
|
||
<a id="app" name="app">Bugs in Anwendungen</a></h2>
|
||
<p>Stürzt eine Anwendung ab, kann man entweder einen 'Bericht' speichern oder eine 'Core-Datei' schreiben (beides erscheint auf dem Desktop). Diese kann man dann an einen Bugreport hängen. Alternativ ruft man den Debugger auf. Siehe dazu das Kapitel <a href="../../userguide/de/applications/debugger.html">Debugger</a>.</p>
|
||
<p>Führt ein Bug nicht zu einen Crash, kann man manchmal wertvolle Informationen sammeln, indem man die Anwendung vom Terminal aus startet. Einige Programme bieten Logging oder andere Optionen an, wenn sie mit entsprechenden Parametern gestartet werden. Einfach mal <tt>-h</tt> or <tt>--help</tt> probieren, um zu sehen ob das der Fall ist. Ein Beispiel für verschiedene Logging-Stufen ist <a href="../../userguide/de/applications/haikudepot.html#logs">HaikuDepot</a>.</p>
|
||
|
||
<h2><a href="#"><img src="../images/up.png" style="border:none;float:right" alt="index" /></a>
|
||
<a id="server" name="server">Bugs in Servern</a></h2>
|
||
<p>Stürzen lebenswichtige Server wie der App Server, der Registrar oder der Input Server ab, bekommt man nicht den gewöhnlichen Crash-Hinweis zu sehen. Stattdessen wird der gesamte Bildschirm weiß und der Debugger wird im Textmodus gestartet, der seine Ausgabe direkt auf den Bildschirm schreibt. Unter Umständen kann man immer noch die Maus bewegen, die daraufhin das Weiß und die Debugger Ausgabe übermalt. Noch laufende Anwendungen, wie ProcessController oder die Uhr in der Deskbar, tun das vielleicht auch noch.<br />
|
||
Außer dass alles etwas unansehnlicher und unbequemer ist, gilt eigentlich das gleiche wie für Bugs in Anwendungen. Am wichtigsten ist das sichern eines "backtrace" mittels <span class="cli">bt</span>. Weil man den Text ja nicht mehr irgendwohin kopieren kann, müsste man die Ausgabe per Kamera festhalten.<br />
|
||
Je nachdem was genau abgestürzt ist, kann man auch probieren mit dem Befehl <span class="cli">save-report</span> einen 'Crash-Bericht' oder per <span class="cli">write-core</span> eine 'Core-Datei' auf dem Desktop zu speichern. Danach sollte man einmal auf den Powerknopf drücken, um zu versuchen den Rechner sauber herunterzufahren. Funktioniert der Powerknopf nicht, gibt es noch die Befehle <span class="cli">shutdown</span> und <span class="cli">reboot</span> zum Ausschalten bzw. für einen Neustart.</p>
|
||
|
||
<h2><a href="#"><img src="../images/up.png" style="border:none;float:right" alt="index" /></a>
|
||
<a id="kernel" name="kernel">Bugs im Kernel</a></h2>
|
||
<p>Fehler im Kernel haben normalerweise die schwersten Auswirkungen und sind zugleich am schwierigsten zu debuggen. Es gibt unterschiedliche Symptome, die auf ein Problem von Kernel oder Treiber hindeuten:</p>
|
||
<ul>
|
||
<li><p>Das System betritt selbständig das Kernel Debugging Land (KDL) . Der obere Teil des Bildschirms wird weiß und einige Zeilen Text erscheinen. Die zweite Zeile verkündet "<i>Welcome to Kernel Debugging Land...</i>", die darüber beschreibt den unmittelbaren Grund für die Reise ins KDL.</p></li>
|
||
<li><p>Das System führt einen spontanen Neustart aus.</p></li>
|
||
<li><p>Das System friert komplett ein. Die Maus lässt sich nicht mehr bewegen und Anwendungen aktualisieren ihre Oberfläche nicht mehr. Ein wichtiger Test in so einer Situation ist, ob man das KDL noch mit der Tastenkombination <span class="key">ALT</span> <span class="key">SysReq</span> <span class="key">D</span> (<span class="key">SysReq</span> ist dabei meist die <span class="key">DRUCK</span> Taste) erreichen kann. Man sollte zumindest eine Minute warten, ob sich was tut.</p></li>
|
||
<li><p>Das System fährt nicht mehr richtig hoch. Unter Umständen führt es spontan einen Neustart durch oder bleibt an einer Stelle stecken, vielleicht bei einem bestimmten Symbol des Boot-Bildschirms. In letzterem Falle sollte man auch mal ein <span class="key">ALT</span> <span class="key">SysReq</span> <span class="key">D</span> versuchen.</p></li>
|
||
<li><p>Das ganze System oder eine bestimmte Hardwarekomponente funktioniert nicht richtig. Es könnte beispielsweise nur sehr langsam laufen, Fehler könnten auftreten oder etwas funktioniert überhaupt nicht. Verweigert eine Hardwarekomponente die Arbeit komplett, sollte man natürlich erst mal checken, ob Haiku sie momentan überhaupt treibermäßig unterstützt, indem man zum Beispiel auf der Mainlingliste oder im Forum nachfragt.</p></li>
|
||
</ul>
|
||
<p>Während nur der letzte Punkt explizit auf eine Hardware-Ursache eingeht, können auch alle anderen Symptome auf Fehler in einem Hardware Treiber hindeuten. Hat man einen Verdacht welche Hardware oder entsprechender Treiber mit dem Problem zu tun haben könnte, sollte man prüfen ob das Entfernen oder Deaktivieren von Hardware oder Treiber Abhilfe schafft. Wenn man das Problem beispielsweise beim WLAN vermutet, könnte diese Funktion vielleicht im BIOS ausgeschaltet werden. Wenn nicht, kann man auch den entsprechenden Treiber auf eine "Schwarze Liste" setzen und so im System deaktivieren (siehe <a href="../../userguide/de/bootloader.html">Boot Loader</a>).</p>
|
||
|
||
<h3><a href="#"><img src="../images/up.png" style="border:none;float:right" alt="index" /></a>
|
||
<a id="kdl" name="kdl">Kernel Debugging Land - KDL</a></h3>
|
||
<p>Stürzt das System nicht von selbst ins KDL, kann man das auch absichtlich mit der Tastenkombination <span class="key">ALT</span><span class="key">SysReq</span><span class="key">D</span> erreichen (<span class="key">SysReq</span> ist normalerweise die <span class="key">Druck</span> Taste).<br />
|
||
Im KDL kann es passieren, dass die Tastatur nicht mehr funktioniert. PS/2-Tastaturen gehen immer, bei USB-Tastaturen kommt es auf die Art des USB-Controllers an (UHCI/EHCI). Generell sollte die Tastatur direkt an einem Port hängen, nicht über einen Hub. In bestimmten Fällen kann es sein, dass die Tastatur nur funktioniert, wenn man vorher schonmal per Tastenkombination das KDL betreten hat. USB per OHCI wird zur Zeit noch gar nicht unterstützt.</p>
|
||
<p>Das KDL ist eine Art Konsole. Es lassen sich Befehle eingeben, die Informationen über das System ausgeben. Folgende Befehle sind von besonderen Interesse:</p>
|
||
<table summary="layout" border="0" cellpadding="2" cellspacing="0">
|
||
<tr><td><span class="cli">bt</span> (auch <span class="cli">sc</span>)</td><td> </td><td>Zeigt einen "backtrace" (oder auch "stackcrawl") wo genau der Fehler aufgetreten ist. Ist das System von selbst ins KDL gefallen, wird so ein backtrace automatisch ausgegeben. Der Befehl ist einzugeben, wenn das nicht geschehen oder ein Teil nicht zu sehen ist. Das ist beispielsweise bei sehr langen Ausgaben der Fall. Die einzige Möglichkeit, die Information an die Entwickler zu senden, ist dann ein Foto.</td></tr>
|
||
<tr><td><span class="cli">ints</span></td><td> </td><td>Zeigt die unbenutzten und verwendeten Interrupts.</td></tr>
|
||
<tr><td class="onelinetop"><span class="cli">co</span> (auch "continue")</td><td> </td><td>Verlässt den Kernel Debugger und das System läuft - soweit möglich - normal weiter.</td></tr>
|
||
<tr><td><span class="cli">reboot</span></td><td> </td><td>Führt einen unmittelbaren Neustart durch. Alle nicht gespeicherten Daten gehen verloren und selbst das, was man gespeichert hat, aber noch nicht auf die Platte geschrieben wurde, ist weg.</td></tr>
|
||
</table>
|
||
<p>Weitere Infos gibt es im Artikel <a href="http://www.haiku-os.org/documents/dev/welcome_to_kernel_debugging_land">Welcome to Kernel Debugging Land</a> (Englisch).</p>
|
||
<p>Die Ausgaben im KDL werden zum seriellen Port geschickt. Falls man einen hat und ein entsprechendes Nullmodemkabel samt zweiten Rechner angeschlossen hat. Dort kann man die Ausgaben in einem Terminalprogramm aufnehmen. Außerdem werden sie ins Syslog geschrieben. Wenn man das KDL allerdings nicht verlassen kann, wird auch nichts ins Syslog geschrieben. Es gibt aber eine Debug-Option im Bootloader, die das trotzdem möglich macht (siehe weiter unten).</p>
|
||
<p>Von Ausgaben im KDL lassen sich auch QR-Codes erzeugen, die dann mit einem Smartphone oder ähnlichem zu Text konvertiert werden können. Der Blogpost <a href="http://www.haiku-os.org/blog/mmlr/2012-07-01_qr_encode_your_kdl_output">QR Encode your KDL Output</a> (Englisch) erklärt, wie man mit diesem Feature Daten aus dem Kernel Debugging Land herausbekommt.</p>
|
||
|
||
<h3><a href="#"><img src="../images/up.png" style="border:none;float:right" alt="index" /></a>
|
||
<a id="syslog" name="syslog">Syslog</a></h3>
|
||
<p><b>Das ist die beste Methode, um Informationen über ein nicht-bootendes System zu gewinnen.</b><br />
|
||
Das Syslog (kurz für System Log) enthält wertvolle Infos darüber, was im System abläuft, einschließlich der Ausgaben einer KDL Sitzung. Man sollte es immer an einen Trac Ticket hängen, wenn es etwas mit dem Kernel zu tun haben könnte. Das Syslog befindet sich in der Datei <span class="path">/boot/common/var/log/syslog</span>. Um in eine Datei schreiben zu können, braucht man ein funktionierendes System. Tritt ein Problem im Kernel auf (insbesondere bei spontanen Neustarts und nicht-fortsetzbaren KDL-Sitzungen), kann es passieren, dass es die letzten Ausgaben nicht mehr ins Syslog schaffen.</p>
|
||
<p>Durch die Option <span class="menu">Enable debug syslog</span> im <span class="menu">Debug menu</span> des Bootloaders wird das Syslog im Speicher gehalten.
|
||
Ist die Einstellung <span class="menu">Save syslog from previous session during boot</span> in den Bootloader Optionen aktiviert (wie es standardmäßig der Fall ist), findet man das Syslog der letzten Sitzung unter <span class="path">/boot/system/var/log/previous_syslog</span>.<br />
|
||
Gelingt das Booten nicht, um an das previous_syslog zu kommen, muss man beim Neustart das Bootloader Menü mittels gedrückter <span class="key">SHIFT</span> Taste (bzw. <span class="key">LEERTASTE</span> wenn per UEFI gebootet wird) aufrufen.<br />
|
||
Dort sollte man im <span class="menu">Debug menu</span> die Einträge <span class="menu">Display syslog from previous session</span> und <span class="menu">Save syslog from previous session</span> sehen. Ersterer zeigt das Syslog direkt auf dem Bildschirm an, mit letzterem lässt es sich speichern. Momentan geht das nur auf FAT32 formatierten Medien. Möchte man dafür einen USB-Stick benutzen, den man allerdings erst zu spät reingesteckt hat und der deswegen nicht erkannt wurde, kann man den Rechner nochmals resetten und das Bootloader-Menü erneut aufrufen. Es gilt aber immer noch: Bootet man aus Versehen ein Betriebssystem, sind die Syslog-Daten weg.</p>
|
||
|
||
<h3><a href="#"><img src="../images/up.png" style="border:none;float:right" alt="index" /></a>
|
||
<a id="onscreen" name="onscreen">Debug Ausgabe auf den Bildschirm</a></h3>
|
||
<p><b>Die Ausgabe auf dem Bildschirm ist nur bei ganz bestimmten Situationen sinnvoll und hat bekanntermaßen Timing-Probleme. Es sollte also wirklich nur im Notfall benutzt werden.</b><br />
|
||
Das ist zum Beispiel der Fall, wenn Haiku nicht ganz hochfährt und die <span class="menu">Debug syslog option</span> im Bootloader irgendwie nicht funktioniert. Noch bevor das Haiku-Bootlogo erscheint, die <span class="key">SHIFT</span> Taste (bzw. <span class="key">LEERTASTE</span> wenn per UEFI gebootet wird) gedrückt halten, um das Bootloader-Menü aufzurufen. Von hier in das Menü <span class="menu">Select debug options</span> wechseln und dort weiter unten <span class="menu">Enable on screen debug output</span> aktivieren. (Die anderen Optionen kann man auch mal probieren, um zu versuchen, Haiku erfolgreich zu booten. Wenn Haiku nur mit einer oder mehreren aktivierten Optionen hochfahren kann, sollte man natürlich erwähnen, welche das sind.)<br />
|
||
Abschließend geht man auf <span class="menu">Return to main menu</span> und dann <span class="menu">Continue booting</span>.<br />
|
||
Auf dem Bildschirm werden einige Seiten Text ausgegeben, von denen aber nur die letzten paar für einen Bugreport interessant sind. Der Userguide hat noch weitere Infos zum <a href="../../userguide/de/bootloader.html">Boot Loader</a>.</p>
|
||
|
||
<h2><a href="#"><img src="../images/up.png" style="border:none;float:right" alt="index" /></a>
|
||
<a id="hardware" name="hardware">Bugs von Hardware/Treiber</a></h2>
|
||
<p>Wenn ein Fehler gemeldet wird, der Hardware oder Treiber betrifft, sollten folgende Informationen als Textdateien an den Fehlerbericht angehängt werden:</p>
|
||
|
||
<table summary="layout" border="0" cellpadding="2" cellspacing="0">
|
||
<tr><td>- <span class="cli">listdev</span></td><td> </td><td>Eine detaillierte Auflistung aller vorhandener Hardware inklusive "vendor id" und "pci id"; ähnlich den Befehlen <span class="cli">lshw</span> und <span class="cli">lspci</span> unter Linux.</td></tr>
|
||
<tr><td>- <span class="cli">listusb -v</span></td><td> </td><td>Bei Fehlern im Zusammenhang mit USB, ähnlich dem Befehlt <span class="cli">lsusb</span> unter Linux.</td></tr>
|
||
<tr><td>- <span class="cli">open /var/log/syslog</span></td><td> </td><td>Die zentrale Log-Datei von Haiku, siehe <a href="#syslog">Syslog</a> weiter oben, entspricht der Debug Bildschirmausgabe. Mit dem Befehl <span class="cli">open</span> kann das Log im Texteditor auf eine sinnvolle Länge gekürzt werden.</td></tr>
|
||
<tr><td class="onelinetop">- <span class="cli">listimage | grep drivers/</span></td><td> </td><td>Eine Auflistung aller verwendeten Treiber.</td></tr>
|
||
<tr><td>- <span class="cli">usb_hid_report</span></td><td> </td><td>Sind USB-Eingabegeräte betroffen, sollte man die Datei <span class="cli">/tmp/usb_hid_report_descriptor_*.bin</span> an den Fehlerbericht hängen.</td></tr>
|
||
<tr><td>- <span class="cli">ints</span></td><td> </td><td>Nur im <i>Kernel Debugging Land</i> (siehe weiter oben). Es zeigt eine Liste aller verwendeter "Interrupts". Wenn sich mehrere Geräte zuviele von ihnen teilen, ist das schlecht.</td></tr>
|
||
<tr><td colspan="3">- "On screen debug output" (die Bootloader Debug Option zur Ausgabe auf dem Bildschirm, siehe <a href="#onscreen">weiter oben</a>).</td></tr>
|
||
</table>
|
||
|
||
<p>Die ersten vier dieser Befehle sind im Terminal einzugeben. Mit dem Zusatz "<span class="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>
|
||
|
||
<h2><a href="#"><img src="../images/up.png" style="border:none;float:right" alt="index" /></a>
|
||
<a id="next" name="next">Bug gemeldet. Und dann?</a></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. 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>
|
||
|
||
</div>
|
||
</div>
|
||
|
||
<div class="nav">
|
||
<div class="inner"><span>
|
||
<a href="../welcome_de.html" class="uplink">Welcome</a>
|
||
</span></div>
|
||
</div>
|
||
|
||
</body>
|
||
</html>
|