Archiv des LibreOffice- und OpenOffice.org-Wiki

[ÜberSicht] [TitelIndex] [WortIndex] [SeiteFinden

OpenOffice.org ist eine komplexe Software, die ständig weiterentwickelt und verbessert wird. Obwohl sich ein ganzes Team darum kümmert, Fehler aufzuspüren, können doch nicht alle beseitigt werden, bevor eine Version freigegeben wird.

Trotz der umfangreichen Hilfe, die man in den MailingListen, Internetforen oder NewsGroups findet, ist es manchmal hilfreich, genau zu wissen, ob ein Fehler den Entwicklern bereits bekannt ist. Da OpenOffice.org ein offenes Projekt ist, hat jeder Anwender Zugriff auf nahezu alle Informationen, die auch den Entwicklern zur Verfügung stehen. Hierzu gehört auch die Fehlerdatenbank, der so genannte Issue-Tracker.

1. Einige Hintergrundinformationen

Der Issue-Tracker ist ein Online-Portal, in welchem Fehlermeldungen (bug reports), aber auch Erweiterungswünsche (feature requests) oder Aufgaben (tasks) gesammelt werden. Da es sich um eine komplett webbasierte Lösung handelt, kann der Issue-Tracker mit jedem beliebigen Browser genutzt werden, ohne dass zusätzliche Software installiert werden müsste.

(!)

Der Issue-Tracker ist mit dem bekannterem BugZilla verwandt und trug ursprünglich den Namen „IssueZilla“. In vielen Dokumentationen wird er auch weiterhin so bezeichnet und einige Projektmitglieder behalten diesen Spitznamen für das „Monster“ bei.

Jeder Eintrag wird als „Issue“ bezeichnet, was etwa als „Anliegen“ übersetzt werden kann. Zu jedem solchen Issue wird nicht nur eine möglichst genaue Beschreibung erfasst, sondern auch die einzelnen Bearbeitungsschritte, Verweise auf andere Fehler sowie ein voraussichtlicher Zeitpunkt für die Korrektur.

Alle diese Informationen werden zu verschiedenen Zeitpunkten von unterschiedlichen Personen erfasst und abgefragt. Zu denen, die mit dem Issue-Tracker arbeiten, gehören u.a.:

Hinzu kommt, dass die Arbeiten fast ausschließlich international koordiniert werden.

Das alles führt dazu, dass die Arbeit mit dem Issue-Tracker sehr umständlich erscheint. Selbst einfache Aufgaben, wie das Auffinden einer Problemmeldung, wirken sehr komplex.

Im Folgenden sollen aber einige Grundregeln dargestellt werden, die es vereinfachen, gezielt nach Informationen in der Fülle der vorhandenen Daten zu suchen.

2. Einstieg in den Issue-Tracker

Der Issue-Tracker ist für jeden zugänglich. Wer häufiger mit diesem Werkzeug arbeitet, sollte sich auf den Webseiten von OpenOffice.org registrieren, da dann erweiterte Möglichkeiten zur Verfügung stehen. Da wir für den Moment aber nur nach Informationen suchen möchten, genügt es, einfach die Webseite von OpenOffice.org aufzurufen. Auf den deutschsprachigen Seiten rufen Sie am Einfachsten http://de.openoffice.org/dev/ auf.

Am linken Rand jeder Webseite finden Sie einen Bereich mit den Projektwerkzeugen. Von hier aus können Sie den Issue-Tracker erreichen.

projektwerkzeuge.png projecttools.png

Abbildung: Projektwerkzeuge auf den deutschen bzw. internationalen Seiten mit Link zum Issue-Tracker

(!)

Auf einigen wenigen Seiten von OpenOffice.org sind die Links zu den Projektwerkzeugen ausgeblendet. Sollte dies der Fall sein (wie z.B. auf http://de.openoffice.org/) wechseln Sie einfach auf eine andere Seite. Wählen Sie z.B. „Wo ist... ?“ auf der Startseite des deutschsprachigen Projektes.

Die Einstiegsseite des Issue-Trackers präsentiert sich jetzt bereits in englisch. Neben einigen Links zu Informationen bezüglich des Umgangs mit dem Werkzeug, haben Sie die Auswahl, ob Sie eine Suchanfrage starten oder eine neue Problemmeldung aufgeben möchten. Um mit der Suche zu beginnen, klicken Sie auf „Query Database“.

3. Eine einfache Suche

Im Issue-Tracker werden sehr viele Informationen von vielen verschiedenen Benutzern erfasst. Um alle diese Informationen abfragen zu können, ist das Formular für eine detaillierte Suche auch entsprechend komplex. Um sich aber nicht vollends in den Möglichkeiten zu verlieren, genügt es, einige einfache Regeln zu befolgen:

Zur Übung versuchen wir jetzt, einen Fehler im Issue-Tracker aufzufinden. Nehmen wir als Beispiel ein Problem mit DokumentVorlagen. In einigen Versionen von OpenOffice.org kann es vorkommen, dass Dokumentvorlagen nicht im Dialog „Vorlagen und Dokumente“ angezeigt werden, obwohl sie im korrekten Verzeichnis abgelegt wurden. Auf den ersten Blick scheint es keine offensichtlichen Zusammenhänge zu geben, welche Vorlagen angezeigt werden und welche nicht.

Für eine strukturierte Suche sind das relativ wenig Informationen, aber schauen wir, ob sie ausreichen.

Wie in den Regeln oben erwähnt, sollte man mit einer relativ allgemeinen Suche beginnen und Felder, über deren Bedeutung man unsicher ist, eher frei lassen. Das Einzige, was wir mit ziemlicher Sicherheit sagen können, ist, dass es sich um einen Fehler handelt. Markieren Sie also den „Issue Type“ DEFECT.

izs_top.png

Abbildung: Einen Fehler suchen

Beachten Sie, dass für alle anderen Auswahllisten die Standard-Einstellungen gelöscht wurden. Insbesondere das Feld „Status“ sollte geleert werden, da wir nicht wissen, ob der Fehler nicht vielleicht schon in einer Entwicklerversion korrigiert wurde.

{OK}

Um die Auswahl in einem Listenfeld vollständig zu leeren, wählen Sie zuerst einen einzelnen Eintrag aus. Halten Sie dann die Strg-Taste gedrückt und klicken noch einmal auf den Eintrag.

Unbedingt benötigt wird noch ein guter Suchbegriff für das Feld „Summary“. Der englische Begriff für Dokumentvorlage, template, sollte für den Anfang genügen. Das entspricht der Regel, zuerst allgemein zu suchen und nachher die Suche zu verfeinern. Gehen Sie also im Formular nach unten, suchen das Feld „Summary“ und geben dort template ein.

izs_bottom.png

Abbildung: Nach dem Begriff "template" suchen

Die Suche kann dann über die Schaltfläche „Submit query“ gestartet werden, die Sie sowohl am oberen als auch am unteren Ende des Formulars finden, und liefert eine Liste von Problembeschreibungen. Nur leider ist diese mit über 450 Treffern für unsere Zwecke zu groß. Die Suche muss also verfeinert werden.

(!)

Es ist unter Umständen trotzdem sinnvoll, einige der Problemmeldungen zu lesen, um mögliche Suchbegriffe für die nächste Anfrage zu ermitteln.

Jetzt beginnt der eigentlich anspruchsvolle Teil unserer Suche, das Aufspüren eines guten Suchbegriffes. Überlegen wir, was wir über unser Problem wissen.

Die Vorlagen werden nicht angezeigt. Wir können das Feld „Summary“ also um die Begriffe „not shown“, „not displayed“ oder „not visible“ erweitern. Vergessen Sie nicht, die Option neben dem Feld auf „all words / strings“ zu stellen.

Versuchen Sie diese Möglichkeiten und schauen sich die Ergebnisse an, auch wenn sie – leider – nicht zum Erfolg führen. Die Suchanfrage wird zu stark eingeschränkt und es werden keine relevanten Treffer gelistet. Wir benötigen also einen besseren Suchbegriff.

Das Problem wurde im Dialog „Vorlagen und Dokumente“ beobachtet. Falls Sie wissen, wie dieser Dialog in einer englischen Version heißt, können Sie nach der Dialogbezeichnung suchen. Für den Moment soll es uns aber genügen, die Anfrage um den Hinweis zu erweitern, dass es sich um einen Dialog handelt.

Wechseln Sie also wieder zurück zum Anfrageformular und geben Sie im Feld „Summary“ die Begriffe template dialog ein.

Nachdem die Anfrage abgesendet wird, werden ca. 25 Treffer aufgelistet. Das ist eine Anzahl, bei der es lohnt, die Beschreibungen genauer durchzusehen. Issues, in denen explizit auf einen Absturz (crash) hingewiesen wird oder die sich auf Spezialfälle beziehen (z.B. „arabic:“ oder „Testtool:“ in der Summary) können ignoriert werden.

Nach wenigen Minuten sollte deutlich werden, dass Issue 45558 (Templates with Keywords not showed in File - new - templates and documents dialog) das gesuchte Problem beschreibt.

4. Die gefundenen Informationen bewerten

Wir wissen jetzt, dass unser Problem den Entwicklern bekannt ist. Aber was fangen wir mit diesem Wissen an – und noch viel wichtiger, was fangen die Entwickler mit unserem Problem an?

Schauen wir uns den Issue deshalb etwas genauer an. (Ich beziehe mich auf den Issue-Stand im Juni 2006, kurz vor Erscheinen von OpenOffice.org 2.0.3).

Den größten Teil des Problemreports machen die Kommentare der Anwender und Entwickler aus. Diese sind zwar sehr umfangreich, aber deshalb interessant, da sie einen Hinweis enthalten, wie man das Problem umgehen kann, solange es nicht in OpenOffice.org behoben ist: werden in der Vorlage enthaltene Schlüsselwörter aus den Dateieigenschaften entfernt, wird die Vorlage danach wieder korrekt angezeigt.

Interessanter ist es aber, ob an einer Problemlösung gearbeitet wird und wann mit einer Korrektur zu rechnen ist. Diese Informationen lassen sich bereits aus den Kopfdaten des Issues ablesen.

So hat der Issue den Status „STARTED“. Das bedeutet, dass das Problem von einem Entwickler aufgegriffen wurde und dieser auch bereits an einer Lösung arbeitet.

Wann die Korrektur bereitstehen soll, lässt sich am Feld „Target milestone“ erkennen. Hier ist „OOo 2.0.4“ eingetragen. Da zur Zeit ca. alle drei Monate eine neue Version von OpenOffice.org erscheint, wäre also im Herbst 2006 mit der Lösung des Problems zu rechnen.

Damit wären auch schon die wichtigsten Felder, die zum Auffinden oder Bewerten einer Problemmeldung benötigt werden, genannt. Alle weiteren Felder sollen im Folgenden nur noch überblicksmäßig beschrieben werden.

5. Die Felder im Überblick

Ein Issue enthält sehr viele Daten, die in speziellen Feldern hinterlegt sind und für eine detaillierte Suche oder für weitere Informationen herangezogen werden können.

Schauen wir uns zuerst die Felder an, die im Suchformular zur Verfügung stehen.

(!)

Für die meisten Suchfelder können kurze Erklärungen aufgerufen werden, indem man auf den Link im Titel des Feldes klickt.

Das Feld „Issue Type“ beschreibt die Art des Issues. Bei einem DEFECT handelt sich um einen Programmfehler. Erweiterungswünsche oder Anfragen nach neuen Programmfunktionen werden den Typen ENHANCEMENT oder FEATURE zugeordnet. Die konkrete Zuordnung zu einer dieser Kategorien basiert auf objektiven Kriterien, was bereits im Programmcode enthalten ist, nicht auf dem subjektiven Empfinden der Entwickler oder Anwender. Diese drei Typen sind für die Problemsuche interessant. Weniger relevant sind TASK (allgemeine Aufgaben innerhalb des Projektes) oder PATCH (konkrete Codebeiträge von Entwicklern).

Die Bereiche „Component“ und „Subcomponent“ werden genutzt, um zu bestimmen, in wessen Aufgabenbereich ein Issue gehört. Für eine Suchanfrage sind diese Felder nur begrenzt sinnvoll. Nur wenn ein Problem eindeutig einem Programmodul zugeordnet werden kann, sollte man das Feld „Component“ entsprechend einschränken. Oft benötigte Einträge sind hier:

Sie sollten aber daran denken, dass OpenOffice.org hoch integriert ist. Viele Komponenten werden deshalb modulübergreifend benutzt und können (auch bei der Suche im Issue Tracker) keiner einzelnen Applikation zugeordnet werden.

Das Feld „Status“ enthält die Information über den Bearbeitungsstand eines Issues. UNCONFIRMED, REOPENED oder NEW bedeutet, dass das Problem aufgenommen wurde und evtl. noch weiter untersucht werden muss. Befindet sich der Issue im Status STARTED, arbeitet ein Entwickler an der Problemlösung. Ist das Problem im Quellcode von OpenOffice.org korrigiert (oder gilt das Problem aus anderen Gründen als gelöst), wird der Status auf RESOLVED gesetzt. Anschließend wird die Problemlösung noch überprüft (VERIFIED) und der Issue geschlossen (CLOSED), sobald die Lösung öffentlich verfügbar ist.

Da dieser Prozess aber projektintern abläuft und die einzelnen Schritte sich nicht in den freigegebenen Programmversionen widerspiegeln, ist der Status des Issues für die Suche nur begrenzt relevant. Zur Bewertung des Bearbeitungsstandes ist er aber sehr interessant.

Sobald ein Problem gelöst wird, also in den Status RESOLVED versetzt wird, wird auch ein Eintrag im Feld „Resolution“ hinterlegt. Im Idealfall ist das natürlich FIXED, d.h. das Problem wurde korrigiert. Recht häufig kommt es vor, das ein Issue als DUPLICATE geschlossen wird. Das heißt, dass das Problem bereits gemeldet wurde. Es wird dann nur noch eine Meldung pro Problem offen gehalten, in den geschlossenen Issues wird auf das „Original“ verwiesen.

In einigen Fällen kann es vorkommen, dass ein Issue als INVALID oder WORKSFORME gekennzeichnet wird. Das ist dann der Fall, wenn sich OpenOffice.org korrekt, aber evtl. anders als vom Anwender erwartet verhält. Auch kann es vorkommen, dass die Projektmitglieder trotz Nachfrage das Problem nicht nachvollziehen können. Sollte man auf solch einen Issue stoßen und der Meinung sein, dass es sich um einen klaren Fehler handelt, kann man weitere Informationen als Kommentar hinterlassen. Das ist aber nur sinnvoll, wenn Sie tatsächlich zur genaueren Beschreibung und letztendlich Lösung des Problems beitragen.

Für die Suche ist das Feld „Resolution“ nur in wenigen Fällen interessant, da man im Allgemeinen keine Kenntnis über den Bearbeitungsstand eines Problems hat.

Mit der Priorität („Priority“) eines Issues wird seine „Wichtigkeit“ bestimmt. In die Suche sollte man diese Information aber erst einbeziehen, wenn man sich über die Abstufung der Prioritäten entsprechend der projektinternen Regeln im Klaren ist. P1 wird fast nie vergeben und gilt nur für Fehler, die die Funktion (oder das Compilieren) von OpenOffice.org komplett verhindern. P2 gilt für Abstürze in wichtigen Programmbereichen oder bei Datenverlust. P3 beschreibt allgemeine Fehler. P4 oder P5 gelten für geringfügige Fehler wie Tippfehler oder kleine Mängel in selten genutzten Dialogen.

Die Felder „Platform“ (Prozessorarchitektur) und „OS“ (operating system) sollten weitgehend selbsterklärend sein. Beachten Sie aber bei der Suche, dass Sie keinesfalls den Eintrag „All“ wählen, wenn Sie nach Fehlern suchen wollen, die auf einem beliebigen System auftreten können. Lassen Sie besser diese beiden Felder komplett leer – es wird dann automatisch über alle Plattformen und Betriebssystem hinweg gesucht.

Oft fehlinterpretiert wird das Feld „Version“. Hier wird nicht etwa jede Version aufgelistet, in der ein Problem existiert. Es wird nur die erste Programmversion genannt, in der ein Fehler entdeckt wurde (genauer: für die das Problem gemeldet wurde). Da es neben den veröffentlichten Versionen auch noch viele Zwischenversionen gibt, sollten Sie es erst nach einiger Erfahrung im Projekt für die Suche benutzen.

Das Feld „Target Milestone“ wurde bereits erwähnt. Hier wird hinterlegt, bis wann ein Problem behoben werden soll. Das erfolgt aber frühestens dann, wenn der Issue einem Entwickler zur Bearbeitung übergeben wurde. In einigen Fällen wird hier auch hinterlegt, dass Entwickler für die Umsetzung gesucht werden (OOo PleaseHelp) oder dass zur Zeit kein konkreter Entwickler mit der Aufgabe betraut ist (OOo later).

Von den weiteren Suchfeldern sind nur noch „Summary“ und „A description entry“ von Interesse. „Summary“ wurde bereits hinreichend beschrieben. Das Feld „A description entry“ kann auf die gleiche Weise verwendet werden, durchsucht aber den kompletten Text aller Kommentare.

Neben den Feldern der Suchmaske findet man in einem Issue aber noch weitere Informationen, die sicher interessant sind.

So können an einen Issue auch Dateien angehängt werden. Diese sind dann unter „Attachments“ zu finden. Hier kann es sich um Beispieldokumente handeln, um das Problem nachvollziehen zu können. Teilweise werden aber auch Vorschläge abgelegt, wie ein Problem zu lösen ist oder wie z.B. ein neuer Dialog aussehen sollte.

In einigen Fällen ist auch der Link „View Issue activity“ zur Bewertung des Arbeitsstandes interessant. Hier kann man einsehen, wann der Issue den Status wechselte, wann er einem Entwickler zugewiesen wurde oder wann er gelöst und überprüft wurde. Anhand der zeitlichen Abfolge lässt sich oft erkennen, wie „schnell“ an einem Issue gearbeitet wird und wie stark er Beachtung findet.

6. Issue-Tracker für Experten

Wer häufiger mit dem Issue-Tracker arbeitet (sei es, um Informationen zu suchen oder um selbst Fehler zu melden), wird schnell mehr Wissen benötigen, als hier vermittelt werden kann.

Einige weiterführende Informationen sind auf den Seiten des deutschsprachigen Projektes zu finden. So ist der Issue-Tracker im Helferbereich (unter http://de.openoffice.org/dev/) beschrieben und belegt auch ein eigenes Kapitel in der Mitarbeiter-FAQ (http://de.openoffice.org/doc/faq/mitarbeiter/).

Die besten Informationen erhalten Sie aber meist, wenn Sie sich direkt an die aktiven Projektmitglieder wenden. Wie überall innerhalb OpenOffice.org helfen hier verschiedene MailingListen weiter. Auf der „Entwicklerliste“ des deutschsprachigen Projektes sind einige erfahrende Anwender des Issue-Trackers eingeschrieben.

Das „QA-Projekt“ (Qualitätssicherung) beschäftigt sich intensiv mit dem Issue-Tracker. So finden Sie hier gleich zwei Mailinglisten, auf denen Sie Hilfestellung erhalten können. Die Anwenderliste (users@qa.openoffice.org) hilft bei der Bedienung des Issue Trackers weiter. Tipps und Tricks der Spezialisten erhalten Sie sicher auf dev@qa.openoffice.org. Bedenken Sie aber, dass beides internationale, also englischsprachige Listen sind.

Wer eher zum Selbststudium neigt, kann sich natürlich in der Online-Hilfe des Issue-Trackers informieren. Diese ist am linken Rand der Webseite verfügbar, solange Sie sich innerhalb einer Anfrage oder eines Issues bewegen. In der Hilfe finden Sie z.B. Informationen, wie man komplexe Suchanfragen abspeichern, die Trefferliste neu formatieren oder direkt als Datei exportieren kann.

Viele dieser erweiterten Möglichkeiten stehen erst dann zur Verfügung, wenn Sie sich auf der OpenOffice.org-Webseite registriert und angemeldet haben. Ein solcher eigener Nutzeraccount hat zusätzlich den Vorteil, dass Sie auf den Issue Tracker und einige andere Projektwerkzeuge direkt von Ihrer eigenen Startseite (zu finden unter „My Pages“) aus zugreifen können.

So ausgerüstet sollte Sie auf dem Weg zum Issue-Tracker-Experten nichts mehr behindern können.

7. Siehe auch


KategorieAllgemeines


LizenzBedingungen | AnbieterKennzeichnung | DatenschutzErklärung | Stand: 2013-04-28