Bugzilla
Allgemeines
Bugzilla ist ein Fehlerverfolgungssystem (bug tracker). The Document Foundation (TDF) benutzt seit Kurzem (01.2015) ein eigenes Bugzilla, mit dem alle LibreOffice-Fehler und auch Fehler anderere Software-Produkte der TDF verwaltet werden.
Allgemeines zu Bugzilla in Wikipedia: Hauptseite
Bugzilla-Startseite der TDF: https://bugs.documentfoundation.org (en)
Struktur der Fehler in Bugzilla: Neben der Zuordnung der Fehler zu den jeweiligen Produkten, werden Sie innerhalb eines Produktes zusätzlich in Komponenten unterteilt.
Fehler in Bugzilla anzeigen
Um bestimmte Fehler zu finden, gibt es in Bugzilla mehrere Möglichkeiten:
- Wenn die Fehlernummer bekannt ist, kann diese direkt in das Suchfeld der Statuszeile eingetragen werden. Der Fehler wird dann sofort angezeigt.
- Bugzilla bietet umfangreiche Möglichkeiten nach bestimmten Kriterien nach Fehler zu suchen. Dieses geht von ganz einfach bis ausgesprochen kompliziert. Nach einem Suchlauf wird eine Fehlerliste angezeigt, die den Suchkriterien entspricht.
- Mit einer Browse-Funktion (Statusleiste) können alle Fehler einer Komponente eines Produktes angezeigt werden. Da es zu vielen Komponenten aber sehr viele Fehler gibt, ist die Browse-Funktion oftmals nur eingeschränkt geeignet.
Kurzer Überblick über die Suchfunktionen:
- Suchfeld in Statusleiste: Die einfachste Suchfunktion ist die Eingabe von einem oder mehreren Suchbegriffen in dieses Suchfeld.
- Simple Search: Nach einem Klick auf Search (Statusleiste), kann man zwischen "Simple Search" und "Advanced Search" auswählen. Beim "Simple Search" kann man neben Suchbegriffen auch den Status als Suchkriterium verwenden.
- Advanced Search: Beim "Advanced Search" kann man praktisch alle Informationen, die zu einem Fehler vorhanden sind, als Kriterien für einen Suchlauf verwenden. Aufgrund der vielfältigen Möglichkeiten braucht es hier etwas Übung.
Fehlerverfolgung mit Bugzilla
Basis für die Fehlerverfolgung ist ein definierter Ablauf (life cycle), d. h. je nach Bearbeitungsstand befindet sich ein Fehler in einem definierten Status. Eine detaillierte grafische Darstellung findet man auf dieser Bugzilla-Seite (en).
Idealisiert und vereinfacht sieht die Fehlerverfolgung wie folgt aus:
- Ein Bug wird durch den Reporter gemeldet. Der Fehler erhält den Status UNCONFIRMED. Wie ein Fehler gemeldet wird, ist auf der Seite Fehlermeldung beschrieben. Einen Fehler melden kann grundsätzlich jeder Nutzer von LibreOffice.
- Durch ein Mitglied der Qualitätssicherung wird der Fehler geprüft und bewertet. Falls der Fehler reproduzierbar ist und als Fehler betrachtet wird, erhält er den Status NEW. Diese Prüfung und Bewertung wird im Englischen als Bug Triage (en) bezeichnet.
- Ein Entwickler beginnt mit der Behebung des Fehlers auf der Hauptentwicklungsreihe (master). Damit nicht mehrere Personen gleichzeitig an der Behebung arbeiten, setzt der Entwickler den Status auf ASSIGNED.
- Nachdem der Fehler durch den Entwickler behoben wird, erhält der Fehler den Status RESOLVED FIXED. Je nach Schwere des Fehlers kann der Entwickler die Fehlerkorrektur auch in die aktuellen Entwicklungsreihen übertragen (backport).
- Zuletzt sollte unabhängig geprüft werden, ob der Fehler wirklich behoben ist. Dies kann z. B. durch den Reporter oder durch ein Mitglied der QA erfolgen. Der Fehler erhält dann den Status VERIFIED CLOSED.
Volle Transparenz der Fehlerverfolgung: Alle Schritte von der Meldung des Fehlers durch den Reporter bis zum Schließen eines Bugs werden in Bugzilla mit entsprechenden Zeitstempeln gespeichert. Jeder kann diese Informationen einsehen. Auf der Fehlerseite werden der ursprüngliche Fehlerbericht und alle nachfolgenden Kommentare chronologisch angezeigt. Änderungen der im oberen Bereich angezeigten Statusinformationen findet man, wenn man auf "History" klickt.
Erklärungen zu einzelnen Feldern von Fehlern in Bugzilla
Status
Neben den oben genannten Statusinformationen UNCONFIRMED, NEW, ASSIGNED, RESOLVED FIXED und VERIFIED CLOSED gibt es einige weitere Statusinformationen:
- WORKSFORME: Die QA konnte keinen Fehler feststellen. Möglicherweise müssen in diesem Fall weitere Informationen durch den Reporter bereitgestellt werden, damit der Prüfer den Fehler reproduzieren kann.
- REOPENED: Dieser Status ist ausschließlich für den Fall vorgesehen, wenn ein Fehler bereits durch einen Entwickler (vermeintlich) korrigiert und als FIXED gekennzeichnet wurde, der Fehler aber nicht, nicht vollständig oder fehlerhaft korrigiert wurde. Für alle anderen Fälle, in denen der Fehler nicht durch den QA-Prüfer (Triage) anerkannt wurde (Status: WORKSFORME, WONTFIX, INVALID), man aber meint dass dies falsch, ist der Status auf UNCONFIRMED zurückzusetzen. Dies sollte dann aber auch in einem Kommentar begründet werden.
- INVALID: Das beschriebene Verhalten ist kein Fehler, sondern so beabsichtigt.
- WONTFIX: Das beschriebene Problem ist ein Fehler, der aber aus bestimmten Gründen nicht behoben werden wird.
- DUPLICATE: Der Fehler ist bereits in einem anderen Bug Report beschrieben worden. Die Nummer dieses Bugs wird angegeben und ist direkt zu diesem Bug verlinkt. (Beispiel: "RESOLVED DUPLICATE of bug 45789")
Whiteboard
Im Feld Whiteboard werden definierte Begriffe eingetragen, um die Fehlerverfolgung zu organisieren. Diese werden üblicherweise von der QA oder von Entwicklern eingetragen. Obwohl man frei ist, alles einzutragen, sollten nur die in der Whiteboard-Liste (en) definierten Begriffe verwenden.
Informationen zu weiteren Feldern
Informationen zu weiteren Feldern findet man auf der Seite Detailinfos.