Bugzilla-Anleitung

Wie kein anderer Browser (jaja, das ist eine Verkürzung;-) ist SeaMonkey in der Entwicklung, SeaMonkey ist aber auch ein Gemeinschaftsprojekt. Koordiniert wird die Arbeit entscheidend durch das System Bugzilla (https://bugzilla.mozilla.org/), das Bugs und Verbesserungsvorschläge sowie deren Lösung in einer Datenbank organisiert.

Hat man also ein Problem, sollte man also dort schauen, ob das bekannt ist, ggf. gibt es eine Lösung. Anderenfalls sollte man den Fehler melden.

Bugs finden

Wie also findet man etwas in Bugzilla? Mit Erfahrung. Also üben;-) Der erste Schritt ist, dass man Schlüsselbegriffe des Problems auf der Startseite von Bugzilla oben Links in das Suchfeld eingibt. Dabei Wortstämme verwenden (es wird nach Substrings gesucht!), das erhöht die Trefferchance. Hat man zu viele Ergebnisse, so ist es meist hilfreich, auf der Ergebnisseite mit der entsprechenden Browserfunktion zu suchen. Nun kann es sein, dass nichts dabei ist oder von Anfang an zu wenig angezeigt wird. Das heißt nichts! Diese "Billigsuche" ist relativ schlecht konzipiert, sie findet nämlich nur Bugs, für die es keine Lösung gibt. Dabei gehen einem insbesondere all die Bugs ab, die auf was anderes gedupet wurden (d.h., die Bugmeldung war schon vorher bekannt, die Lösung ist dann ein Verweis auf den alten Bug); oft erkennt man die Beschreibung (Summary) aber nur bei den Dupes, also möchte man die auch finden.

Wie findet man wirklich das, was man sucht? (31337-8u6zi114-5k1llz) Man geht auf die Query Page. Diese ist hoffnungslos unübersichtlich, fast nichts davon braucht man. Egal, wir konzentrieren uns auf das wesentliche ("pi's Simplified Bugzilla Query" benutzt nur die hier besprochen Felder): Beim Status alle auswählen. Dann vorläufig nichts anfassen, wenn man nicht ganz genau, was man damit will, vor allem nicht auf das OS beschränken, wenn man nicht sehr genau weiß, warum man das tut. Dann kann die Auswahl von Program nützlich sein. Ich sage kann. Wer hiermit nichts anfangen kann, lasse es. Hierbei geht es darum, welche Komponente für den Bug verantwortlich ist; das ist nicht immer offensichtlich! (Z.B. sind zahlreiche MailNews-Bugs in Browser angeordnet, da der Editor eben Teil des Browsers ist.) Andererseits kann eine Einschränkung hier sehr hilfreich sein. Wer sich sehr gut auskennt (aber der braucht diese Anleitung eh nicht;-), kann noch die Component auswählen, natürlich ist eine Mehrfachselektion oft nützlich, das geht auch in Verbindung mit Program (z.B. Program: Browser und MailNews, Component: Editor: Core und Internationalization). Soweit haben wir jetzt den Rahmen abgesteckt. Die eigentliche Suche wird sich meist auf die Summary erstrecken. Hier gilt dasselbe wie oben gesagt (Wortstämme). Abschicken nur (!) mit dem "Submit query" Button.

Bugs melden

OK, nehmen wir an, da ist ein Bug, den man beim besten Willen (und ich meine besten Willen!) nicht finden kann. Zur Sicherheit auf jeden Fall noch einen Blick in die Liste der meistgemeldeten Bugs werfen. Es wäre auch eine gute Idee, den Fehler möglichst mit einer aktuellen Version zu überprüfen; oft werden Fehler gemeldet, die inzwischen gefixt sind. Noch da? Also rein damit. HALT! Es ist eine gute Idee, wenn man noch keine Erfahrung hat, jemanden zu fragen, der sich mit sowas auskennt. Also in der Gruppe de.comm.software.mozilla posten. Bitte nur ein Bug pro Thread. Wer Hilfe beim Finden eines (vermutlich) existierenden Bugs braucht, könnte z.B. [DUPEME] am Anfang des Subjects setzen. DUPEME wird bei Bugzilla (status whiteboard) zur Kennzeichnung von Bugs genutzt, die jemand für einen Dupe hält, aber nicht findet, von welchem Bug. Gibt es in der Gruppe keine Lösung, kann man also wirklich rangehen und den Bug melden.

Einen Bug melden. Hier bitte ausgesprochen sorgfältig arbeiten. Viele Bugreports sind ausgesprochen schwer lesbar, oft fehlen wesentliche Informationen. Denkt darüber nach, dass das jemand verstehen soll, der nicht die geringste Idee hat, was Euer Problem ist. Bitte benutzt den Bugzilla Helper, um Euren Bug zu melden, dabei lernt Ihr gleichzeitig, worauf man achten muss. Das ist anfangs sehr aufwendig, wenn man es aber einmal kann, ist es sehr viel einfacher. Einfach der Anleitung folgen. Auf keinen Fall fehlen darf die Version, die Ihr gerade verwendet (am besten den ganzen Ausdruck aus Help/About SeaMonkey kopieren); ebenfalls angeben, wenn Ihr andere als die Standard-Themes nutzt, bitte dies auch angeben. Was Platform/OS angeht, könnte Feedback in der Gruppe hilfreich sein. Ganz wichtig ist die Summary. Hier sollten Buzzwords stehen. Damit kann man den Bug dann finden; wonach habt Ihr oben gesucht? Damit sollte man diesen Report finden können. Die Beschreibung sollte möglichst präzise sein ("klappt nicht" ist nicht hilfreich). Gesucht ist eine exakte Problembeschreibung. Wenn das jemand überprüft, will er wissen, wo genau er hinschauen soll. Es ist reichlich frustrierend, auf einer kilometerlange Webseite nach einem Darstellungsfehler zu suchen, wenn es keinen Anhalt gibt. Die Frage, ob das reproduzierbar ist, sollte man tunlichst beantworten können. Das nicht probiert zu haben, spricht meist dafür, dass der Bug nicht so ernst sein kann (Ausnahmen könnten bei Abstürzen gegeben sein). Wenn schon Du es nicht reproduzieren kannst, wie sollen es andere tun? Steps to reproduce sind wichtig, das will jemand nachvollziehen. Natürlich braucht man nicht zu schreiben "Go to URL, see". Dann besser ganz löschen, wenn es aus der Description völlig (völlig) klar ist. Sonst in so vielen Punkten beschreiben, wie man braucht (bei Bedarf löschen oder ergänzen, es müssen wirklich nicht genau drei Punkte sein). Das nächste mag albern erscheinen, ist aber sehr nützlich zur Übersicht. Einfach noch mal kurz sagen, was passiert und was eigentlich hätte passieren sollen. Nicht die Severity übersehen, aber nicht übertreiben; vor allem sollte ein Verbesserungsvorschlag auch Enhancement heißen (in den meisten Fällen sind diese unabhängig von Platform/OS, s.o.). Dann noch abschicken (Achtung, zwei mal!).

Je besser der Report, desto nützlicher ist er. Und natürlich kann er so umso leichter bestätigt werden. Und das mit weniger Zeitaufwand (Zeit, die für anderes zur Verfügung steht!). Und desto größer die Chancen, dass sich jemand schnell drum kümmert.

Bearbeiten bestehender Bugs

Was, wenn Du einen Bug gefunden hast, der Dich betrifft? Zunächst einmal kannst Du Dich freuen, dass sich schon jemand gekümmert hat. Jetzt kommt es auf zweierlei an. Zunächst einmal auf den Status des Bugs, dann darauf, welche Rechte Du hast. Fangen wir mit letzterem an. Bei den Bugzilla-Einstellungen zu Deinem Account unter Permissions steht, was Du darfst (oder auch nicht). Typischerweise darfst Du nur an den Bugs was verändern, die Du selbst gemeldet hast. Dann gibt es noch priviligierte User, die alles ändern können (für die ist dieser Text hier nicht gedacht).

Bugs, die Du gemeldet hast

Du hast also gemäß obiger Anleitung einen Bug gemeldet. Dieser hat automatisch den Status UNCONFIRMED. Viele Helfer werden schauen, ob sie damit was anfagen können, werden ggf. Korrekturen vornehmen (bessere Summary, andere Komponente etc.) oder den Bug bestätigen (dann hat er den Status NEW). Evtl. nimmt sich jemand des Problems an (Status ASSIGNED). Wenn man zu dem Ergebnis kommt, dass das beschriebene Problem nicht reproduzierbar ist, wird der Fehler als gelöst markiert (RESOLVED/WORKSFORME). Gibt es den Bug schon, wird darauf verwiesen (RESOLVED/DUPLICATE). Wird festgestellt, dass es gar kein Bug ist (sondern ein Feature oder korrektes Verhalten), so wird der Bug abgelehnt (RESOLVED/INVALID). Schließlich gibt es noch Fehler, die man aus unterschiedlichsten Gründen nicht beheben will (RESOLVED/WONTFIX). Nicht verwendet werden sollten die Statusbeschreibungen CLOSED, LATER und REMIND. Wenn eine Lösung bestätigt wird, ersetzt man RESOLVED durch VERIFIED (Das solltest Du auf keinen Fall machen; wenn Du es eh besser weißt, würdest Du diesen Text nicht lesen …).

Es wird vorkommen, dass die Angaben in der Bug-Meldung unzureichend sind. Dann wird jemand nachfragen. Das ist kein Grund, sauer zu reagieren. Typische Fragen lauten:

Beantworte also bitte geduldig die Fragen, so präzise wie möglich. Veränderungen an den Einstellungen des Bugs solltest Du nicht vornehmen, wenn Du nicht sehr genau weißt, was Du tust, auf keinen Fall jedoch Bereiche, die nur dem zustehen, dem der Bug gehört (Assigned To): Priority und Target Milestone. Auch wird derjenige die anderen Felder meist besser beurteilen können, also Vorsicht!

Bugs, die andere gemeldet haben

Gelegentlich wirst Du zu Bugs, die von anderen gemeldet wurden, etwas beitragen können. Hier gilt das gleiche wie im vorstehenden Fall. Achte besonders darauf, ob Deine Anmerkung etwas neues beiträgt. Ein "stört mich auch" ist nicht hilfreich. Nützlich kann sein, dass Du mit einer gänzlich anderen Version (anders OS, anderer Branch) den Bug nachvollziehen kannst oder auch nicht. Evtl. konntest Du den Fehler einschränken (genauere Tatumstände sozusagen). Oder Du hast einen Testcase gebastelt.


Valid CSS!Valid HTML 4.01!
© Boris 'pi' Piwinger, August 27, 2002