De DE/FehlerUndWünsche
From FedoraProject
Contents |
Fehler und Wünsche - Regeln für Bugzilla-Berichte
Bugzilla ist das vom Fedoraprojekt verwendete Werkzeug für das Melden und Verfolgen von Fehlern oder neuen Anforderungen.
Manchmal fehlen diesen Berichten benötigte Informationen, sind nicht korrekt oder haben andere Fehler. Das vergeudet wertvolle Zeit, sowohl beim Verfasser des Berichts als auch bei den Entwicklern, die mehr Zeit bei der Fehlerverfolgung benötigen. Das kann sogar dazu führen, dass dieser Bericht vergessen oder ignoriert wird. Diese Seite beschreibt, wie Fehlerberichte qualitativ hochwertig verfasst werden und gibt konstruktive Empfehlungen für Erweiterungen.
Anmerkungen
- Das Fedoraprojekt hat das Ziel, eine ausschliesslich aus freier und quelloffener Software bestehende Plattform zu sein. Empfehlungen zur Aufnahme von proprietärer oder anderer rechtlich problematischer Software ist nicht konstruktiv. Lesen Sie dazu die Seite " Verbotene Elemente ".
- Wenn eine spezielle Software oft verwendet wird, ist es wahrscheinlicher, dass die Anwender Fehler finden oder Erweiterungen vorschlagen. Das bedeutet nicht, dass diese Software mehr Fehler enthält.
- Entwickler bestätigen Fehlerberichte normalerweise nicht bzw. geben keine Kommentare ab, solange sie keine substanziellen Rückmeldungen haben oder weitere Informationen von Ihnen benötigen. Lassen Sie sie kommen!
- Das Fedora Bug Triaging-Team sucht aktiv nach weiteren Freiwilligen. Wenn Sie interessiert sind, lesen Sie bitte die BugZappers-Seite.
- Bugzilla führt nur die Quellpakete auf. Wenn Sie beispielsweise einen Fehlerbericht zu
mounteinreichen wollen, finden Sie das Quellpaket mit dem folgenden Kommando:
rpm -q --qf "%{SOURCERPM}\n" -f /bin/mount
Ausgabe:
util-linux-2.13-0.10.pre5.src.rpm
Anfang
- Wenn Sie neu in Fedoras Bugzilla sind, müssen Sie zunächst einen Account registrieren. Das ist ein kurzer Prozess, daher sollten Sie nicht zögern:
https://bugzilla.redhat.com/bugzilla/createaccount.cgi
- Lesen Sie die FAQ zu wichtigen Details zu Fedoras Bugzilla:
https://bugzilla.redhat.com/bugzilla/page.cgi?id=redhatfaq.html
- Wenn Sie einen Fehler berichten, ist es hilfreich, wenn Sie die korrekten Angaben zu Produkt, Version und Komponenten auswählen. Damit erreichen Sie den Entwickler / Verwalter des betroffenen Pakets direkt, was beim schnelleren Beheben des Fehlers hilft. Wenn Sie es der falschen Komponente zuweisen, kann es der richtigen Komponente noch zugewiesen werden. Daher sollten Sie den Fehlerbericht versenden, auch wenn Sie nicht sicher sind, ob Sie ihn der richtigen Komponente zugewiesen haben.
- Weitere Regeln zum Einstieg finden Sie unter http://www.redhat.com/magazine/020jun06/features/bugzilla/
Nutzer-Etiquette
Verstehen von Status und Lösung
Nach dem Berichten bekommen Sie möglicherweise Rückmeldungen von anderen Nutzern oder den Entwicklern, die Status ändern und/oder Lösung zum Fehlerbericht sind. Als Erklärung:
https://bugzilla.redhat.com/bugzilla/page.cgi?id=fields.html#bug_status
Fehler berichten
Erweiterungen anfordern
Beim Melden fügen Sie bitte das Schlüsselwort "FutureFeature" dem Bericht hinzu. Stellen Sie sicher, dass Sie ausreichend Informationen und Grundlagen für Ihre Anforderung geben, damit Sie berücksichtigt werden kann.
Sicherheit
Wir achten ganz besonders auf sicherheitsrelevante Fehler. Lesen Sie die Seite Security Bugs , um den besonderen Prozess zu verstehen.
Debugging
- StackTraces
- JavaStackTraces
Kernel
Wenn Sie einen Bericht zu Systemabstürzen oder zum Einfrieren des Rechners einreichen wollen, prüfen Sie bitte vorher, dass es kein bekanntes Hardwareproblem ist:
Die korrekte Versionsnummer, Ausgaben von lspci und ifconfig, andere Hardwareinformationen und eine Zusammenfassung weiterer von Ihnen vorgenommenen Veränderungen am System sind hilfreich. Wenn Sie einen selbstgebauten Kernel verwenden, berichten Sie es bitte stattdessen dorthin.
Xorg
Informationen zur Fehlersuche in Xorg unter Fedora finden Sie auf Xorg Debugging .
OpenOffice.org (OOo)
OOo ist ziemlich gross, verweist auf vieles und verwendet eine Menge weiterer Dinge, so dass es potenziell auch eine Menge Probleme mit sich bringt, die nicht zwangsläufig OOo-Fehler sind, daher...
- Ein Absturz beim Start könnte auch von einer OpenGL-Bibliothek verursacht worden sein, nicht OOo selbst.
- Holen Sie sich die Testquellen von [1] .
- Führen Sie
gcc testgl.c -o testgl -L/usr/X11R6/lib -lX11 -lGLaus, um es zu kompilieren. - Wenn es dann abstürzt, ist es wahrscheinlich kein OOo-Fehler.
- Wenn es auf einer x86_64-Kiste stattfindet, denken Sie dran, dass OOo eine 32-bit-Applikation, Firefox ist eine 32-Bit-Applikation auf der gleichen Plattform. Schauen Sie nach, ob er das gleiche Problem hat.
- Prüfen Sie, dass ähnliche Programme sich nicht auch so verhalten. Wenn also
Firefox/gedit/glxgearsdas gleiche wie OOo tun, ist es wahrscheinlich kein OOo-Fehler.
- Wenn der Crashdialog erscheint, kopieren Sie den Stacktrace in Ihren Fehlerbericht.
- Erwähnen Sie, ob Sie KDE oder GNOME verwenden und ob es häufig auftritt. Wenn Sie eine nicht von Fedora geliefertes Thema verwenden, probieren Sie ein unterstütztes.
- Wenn eine Warnung oder Fehlermeldung erscheint, sagen Sie uns deren Inhalt.
- Wenn es nur bei einem bestimmten Dokument auftritt, fügen Sie dies bei. Verkleinern Sie es möglichst soweit wie möglich, solange der Fehler noch auftritt. "Blättern Sie auf Seite 912, wo die Grafik nicht korrekt sitzt" ist weit weniger angenehm als ein Dokument mit nur einer Seite - solange der Fehler reproduzierbar bleibt.
- Wenn Ihrer Meinung nach die Anzeige nicht stimmt, fügen Sie eine Bildschirmkopie bei. Ich könnte Ihre Beschreibung nicht verstehen.
Beispiel: "Die Schriftart des Formulars ist falsch"
Ist die verwendete Schriftart zum Bearbeiten des Formulars oder die der Darstellung verkehrt? Meinen Sie den mathematischen Editor oder die Formeln in calc? Eine Bildschirmkopie hilft bei der Beantwortung dieser und ähnlicher Fragen.
- Versuchen Sie bitte sich auch den Bug zu konzentieren. "dieses andere Ding funktioniert auch nicht" oder "ja, das ist die Lösung, aber es ist nicht so, wie ich es will" -- Mutationen von Bugs ist eine heikle Angelegenheit. Es gibt kein Problem, wenn mehrere Bug-Berichte eröffnet werden. Es viel einfacher, wenn es sicher heraustellt, dass sie gleich sind, sie zusammenzufassen als sie in einzelne aufzutrennen.
- Wenn Ihr Setup in irgendeiner Weise ungewöhnlich ist, erwähnen Sie es.
Beispiele:
- "Mit MS Word unter Wine erstellte .doc-Dokumente können nicht in OOo geöffnet werden" sagt mehr als ".doc-Dateien können nicht mit OOo geöffnet werden"
- "Das Sichern auf ein Samba-Share funktioniert nicht" statt "Speichern funktioniert nicht"
- Installieren Sie wenn möglich debuginfo und geben Sie ein:
$> gdb /usr/lib/openoffice.org/program/soffice.bin (gdb) run -writer (gdb) bt
Fügen Sie den Backtrace in Ihren Fehlerbericht ein.
(-writer sollte ggf. durch -calc -impress -math -draw ersetzt werden.)
- Wenn jemand einen noch nicht bearbeitete Fehler findet, der durch eine neuere Aktualisierung behoben, und dies in einer Fehlermeldung zu einer früheren Version erwähnt. Es ist aber nicht hilfreich, wenn jemand eine UMPROMPTED Nachricht schreibt, dass das Problem noch vorhanden ist.
- "Das ist nicht akzeptabel" motiviert niemanden.
Referenzen
http://www.chiark.greenend.org.uk/~sgtatham/bugs.html
