Wo melden?¶
Die erste Hürde beim Melden eines Bugreports (kurz „Bug“) ist die Frage wo man ihn melden soll. Hier gibt es durch die Strukturierung der freien Software Welt in „Upstream“ (eigentliche Projekte wie KDE und GNOME) und „Downstream“ (Distributionen wie Ubuntu) mehrere Bugtracker zur Auswahl. Das Ubuntu Projekt bietet mit Launchpad 🇬🇧 einen Bugtracker für im Prinzip alle Anwendungen von Ubuntu an. Ein Ubuntunutzer kann also alle Fehler einfach in Launchpad 🇬🇧 melden. Dies ist jedoch nicht immer hilfreich, denn Ubuntu entwickelt bis auf kleine Bereiche keine eigene Software, sondern paketiert die Upstream Anwendungen. Eine Meldung erreicht in dem Fall nicht unbedingt die Entwickler oder nur mit sehr großer Zeitverzögerung. Das „Bug Triaging“ Team muss die Meldung manuell an die Bugtracker der Upstream Projekte weiterleiten.
Auf der anderen Seite ist es manchmal schwer zu erkennen, wo nun der Fehler liegt und wo er daher zu melden ist. Auch muss man um für verschiedene Anwendungen Fehler zu melden sich auf jeder dieser Bugtracker anmelden. Hier ist es nachvollziehbar, dass man lieber nur einen Account wünscht. Sofern man weiß in welcher Anwendung der Fehler auftritt und ihn auch direkt an die Entwickler melden möchte, kann man nach folgender Faustregel vorgehen: Fehler in der Anwendung sind Upstream, Fehler in der Paketierung (z.B. fehlende Dateien) und Zusammenspiel zwischen verschiedenen Anwendungen sind Downstream.
Wie melden?¶
 |
| Einen Fehlerbericht mit Dr.Konqui erstellen (Bild 1 von 6) |
Die einfachste Art und Weise einen Fehler in der Anwendung zu melden, ist den Menüeintrag dafür zu verwenden. Alle KDE Anwendungen haben beispielsweise im Hilfe Menü den Punkt „Probleme oder Wünsche berichten“. Der Vorteil dieser Variante ist, dass die Metadaten direkt richtig gesetzt und der Bug auch bei den Entwicklern landet. Bei Ubuntu wird in der Regel auch ein Menüpunkt eingetragen um einen Bug direkt auf Launchpad zu melden. Auch die Programme, welche über abgestürzte Anwendungen berichten, bieten eine Möglichkeit den Crash direkt zu melden.
Wann melden?¶
 |
| Einen Fehlerbericht mit Dr.Konqui erstellen (Bild 2 von 6) |
Das Ziel des Meldens eines Bugs ist es, die Software zu verbessern und den Fehler zu beseitigen. Hierbei ist es manchmal erforderlich als Melder mit den Entwicklern so zusammenzuarbeiten, dass der Fehler beseitigt werden kann. Ist man dazu nicht bereit, braucht man erst gar nicht den Fehler zu melden: hat der Nutzer keine Lust, dann der Entwickler auch nicht. Einen Fehler sollte man auch nur melden, wenn man weiß wann und wie er auftritt, d.h. man muss in der Lage sein den Entwicklern zu erklären wie sie den Fehler reproduzieren können. Dies ist eine wichtige Voraussetzung um den Fehler überhaupt beheben zu können. Wenn man also keine Ahnung hat was man gemacht hat, als der Fehler auftrat, kann auch der Entwickler nichts daraus ablesen.
Bei einem Crash gibt es leider noch mehr zu beachten. Ohne die zusätzliche Installation von „Debug“ Paketen ist der automatisch generierte Stacktrace wertlos. Dieser zeigt den Entwicklern den Ablauf der Software zum Zeitpunkt des Absturzes. Er bietet also einen kleinen Blick in die Vergangenheit. In Verbindung mit einer guten Anleitung wie man den Crash reproduzieren kann, sollte der Entwickler in der Lage sein den Crash zu identifizieren. In der Standardinstallation sind die Crashmeldungen jedoch nutzlos und zeigen nur „(no debugging symbols found)“. Meldet man solch einen Crash verursacht man den Entwicklern nur zusätzliche und überflüssige Arbeit – der Bugtracker wird zum Fluch. Der KDE Crashdialog „Dr.Konqui“ bewertet die Crash Informationen und informiert den Nutzer, ob es überhaupt sinnvoll ist den Crash zu melden. Es gibt auch direkt die Möglichkeit, die benötigten Pakete zu installieren und danach die Daten neu zu generieren.
 |
| Einen Fehlerbericht mit Dr.Konqui erstellen (Bild 3 von 6) |
Gerade bei einem Crash ist es unwahrscheinlich, dass man als Nutzer der erste ist, bei dem der Crash auftritt. Es ist also denkbar, dass die Entwickler bereits über den Crash informiert sind oder dass er in der aktuellen Entwicklungsversion schon behoben ist. Daher ist es unglaublich wichtig zuerst zu suchen. Hier hilft zum Beispiel Dr.Konqui und sucht automatisch nach möglichen Duplikaten. Ähnlich ist es auch bei Launchpad wo andere Bugs vorgeschlagen werden, die dem gemeldeten ähneln. Werden dabei sehr viele gefunden, so kann man sich die Meldung wirklich sparen, denn sie verursacht wieder unnütze Arbeit bei den Entwicklern. Vor allem sollte man bei Entwicklungsversionen im Zweifelsfall nicht melden.
Das A und O eines guten Bugreports¶
 |
| Einen Fehlerbericht mit Dr.Konqui erstellen (Bild 4 von 6) |
Einige der wichtigsten zu beachtenden Punkte wurden bereits angesprochen. Man sollte immer zuerst suchen ob der Bug schon gemeldet wurde. Dies kann auch manchmal etwas länger dauern und man muss dabei viele mögliche Meldungen lesen. Spart man sich diesen Schritt, so muss der Entwickler genau die gleichen Schritte machen. Anstatt Fehler im Quellcode zu beseitigen ist er mit der Verwaltung der Fehlerreports zuständig. Für das Finden von 10 Duplikaten auf einer Bugmenge von etwa 400 Bugs braucht der Autor dieses Artikels etwa eine Stunde.
Ein Bug sollte immer in Englischer Sprache verfasst werden. Sofern man sich auf Wörter in der Benutzeroberfläche bezieht, ist es hilfreich die Anwendung zuerst einmal auf Englisch zu starten um die richtigen Begriffe zu finden. Eine fehlerhafte Rückübersetzung der Begriffe erschwert die Arbeit der Entwickler.
Der ideale Bug enthält eine genau Anleitung zum Reproduzieren des Bugs, das erwartete Verhalten und das tatsächliche Verhalten. Zusätzliche Informationen können hilfreich sein, jedoch melden sich die Entwickler selbst wenn sie mehr Informationen benötigen. Vermutungen wo der Fehler liegt, gehören nicht in die Fehlermeldung – als Anwender kann man dies nicht wissen.
Hier ein Beispiel eines idealen Bugreports:
Schritte zum Reproduzieren:
Mindestens drei Fenster öffnen
Mindestens zwei modale Fenster in zwei der drei Fenster öffnen (z.B. Datei öffnen in einem und die Einstellungen im zweiten)
Mit Alt+Tab durch die Fenster navigieren
Erwartetes Verhalten: Wechseln der Fenster sollte genauso funktionieren, wie wenn keine modalen Fenster vorhanden sind. Anstatt des Hauptfensters sollte das modale Fenster angezeigt werden.
Tatsächliches Verhalten: Für modale Fenster werden zusätzliche Einträge angelegt, die nicht funktionieren. Die Sortierung ist nicht korrekt.
Der Fehler lässt sich immer mit mindestens zwei modalen Fenstern reproduzieren, bei mehr Fenstern tritt er auch jedes mal auf.
Erwartungshaltung¶
 |
| Einen Fehlerbericht mit Dr.Konqui erstellen (Bild 5 von 6) |
Wenn man einen Fehler meldet, möchte man natürlich, dass dieser so schnell wie möglich behoben wird. Man ist von dem Fehler genervt und er behindert die Nutzung. Dies kann sehr leicht zu einer falschen Erwartungshaltung und Kommunikation führen. Ubuntu ist eine stabile Distribution und Veränderungen an den Paketen werden nur in sehr seltenen Fällen vorgenommen. Ein von den Upstream Entwicklern behobener Fehler wird daher häufig erst mit der nächsten Ubuntuversion behoben sein. Ubuntu garantiert, dass es im Lebenszyklus eines Release keine Regressionen gibt, dies ist zum Beispiel bei einer neuen KDE SC Version, selbst wenn sie nur Bugfixes enthält, nur sehr schwer bis gar nicht möglich.
Man sollte sich auch bewusst sein, dass es meistens mehr Bugs gibt als die Entwickler Zeit haben sie zu beheben. Die Tatsache, dass Entwickler nicht in den Bugreport antworten, bedeutet nicht, dass sie ihn ignorieren. Viele Meldungen werden direkt an die Mailingliste der Entwickler oder in den IRC Channel gemeldet und die Entwickler nehmen ihn zur Kenntnis, haben jedoch nicht immer die Zeit direkt zu kommentieren oder es ist einfach so offensichtlich, dass es keinen Grund zu kommentieren gibt. Da die Zeit der Entwickler eingeschränkt ist, müssen sie abwägen ob sie einen Fehler beheben und wann. Versuche die Entwickler von der Wichtigkeit seines Bugs zu überzeugen sind daher kontraproduktiv. Dass der Bug dem Nutzer wichtig ist, ist schon dadurch gegeben, dass der Bug gemeldet wurde und bei jedem Bug gilt natürlich, dass es der wichtigste Bug aus Sicht des Anwenders ist.
 |
| Einen Fehlerbericht mit Dr.Konqui erstellen (Bild 6 von 6) |
So traurig es ist, muss man an dieser Stelle auch sagen, dass es nicht hilfreich ist, die Entwickler im Bugreport zu beschimpfen oder Vergleiche zu machen, wie dies behoben wurde, jedoch jenes nicht implementiert wurde. Auch sollte man nicht in jeder Version eintragen, dass der Bug immer noch nicht behoben ist. Es ist die Aufgabe des Bugtrackers nicht behobene Bugs zu verwalten. Natürlich sollte man Bugs schließen, wenn man feststellt, dass sie nicht mehr auftreten. Man sollte auch davon Abstand nehmen Entwickler, deren EMail Adresse oder IRC Namen man kennt, persönlich zu kontaktieren um die Wichtigkeit des Bugs herauszustellen. Die Wahrscheinlichkeit, dass der Entwickler deswegen den Fehler behebt steigt nicht.
Abschließend sei noch einmal gesagt, dass die Wahrscheinlichkeit, dass ein Bugreport beachtet und behoben wird mit der Qualität des Reports in direktem Zusammenhang steht.
Über den Autor¶
Martin Gräßlin ist ehrenamtlicher Entwickler des Fenstermanagers der KDE SC. Zu den Aufgaben eines Open Source Entwicklers gehört auch die Verwaltung des Bugtrackers. Im letzten halben Jahr wurde beim Produkt KWin 468 Bugs gemeldet, wovon etwa 40 Prozent Duplikate sind. KWin hat aktuell etwa 400 offene Reports. Vergleicht man die Zahlen, so sieht man, dass die Entwickler hauptsächlich mit der Verwaltung von Bugs beschäftigt sind. Die Reduktion „fehlerhafter“ Bugreports erleichtert die Arbeit und ermöglicht es, die echten Bugs im Quellcode und nicht im Bugtracker zu beheben.
Vielen Dank an martingr für diesen ausführlichen Artikel!
