Umgang mit Programmfehlern

Programmfehler in Inkscape werden über GitLab (benutzerorientierter Tracker; entwicklerorientierter Tracker) und über unseren alten Tracker auf Launchpad gemeldet und verwaltet. Benutzer können Fehlerberichte erstellen, sie kommentieren und sich selbst als Bearbeiter eines Fehlers festlegen. Mitglieder des Inkscape-Bug-Teams können den Status von Fehlerberichten setzen und Schlagworte vergeben.

Wichtige Links

• Fehlerberichte zu Inkscape auf Launchpad - diese müssen nach GitLab übertragen werden. Beginne hier mit Deiner Arbeit am Fehlermanagement.
• Fehlerberichte zu Inkscape auf GitLab
• Inkscape-Bug-Team - wende Dich auf der Mailingliste oder im Chat an die Entwickler, um ins Team aufgenommen zu werden.

Fehlerstatus

Launchpad kennt verschiedene Zustände für Bugs. Hier wird erklärt, wie diese in der Inkscape-Entwicklung Anwendung finden.

• New (neu): dieser Fehler wurde gerade erst gemeldet. Es ist nicht bekannt, ob er reproduziert werden kann. Versuche, ob Du dieses Problem auf Deinem Computer nachstellen kannst.
• Confirmed (bestätigt): dieser Fehler konnte nachvollzogen werden, und es ist gesichert, dass der Grund für sein Auftreten in Inkscape liegt. Du kannst daran arbeiten, herauszufinden, was ihn verursacht und ihn reparieren.
• Triaged (gesichtet): ein Mitglied des Bug Teams hat den Fehler bestätigt, und ihn gewichtet. Die Inkscape-Entwickler wissen, dass dieser Fehler behoben werden sollte.
• In Progress (in Bearbeitung): jemand arbeitet gerade daran, den Fehler zu beheben. Verwende diesen Status nicht, um damit zu sagen, dass Du an diesem Fehler arbeiten möchtest, oder dass Du ihn irgendwann später mal beheben wirst. Setze diesen Status nur dann, wenn Du auch tatsächlich damit angefangen hast, an einer Lösung dafür zu arbeiten.
• Fix Committed (repariert): dieser Fehler ist in der Entwicklerversion (lp:inkscape) behoben. Wenn Du eine Lösung hochgeladen hast, aber nicht ganz sicher bist, ob diese auch funktioniert, weil das Problem z.B. nur auf einer Plattform auftritt, zu der Du keinen Zugang hast, lasse den Status auf "In Progress".
• Fix Released (veröffentlicht): dieser Fehler ist in der aktuellen, stabilen Inkscape-Veröffentlichung behoben. Verwende diesen Status auch für Probleme, die nur in der Entwicklerversion aufgetreten sind, und nie in einer stabilen Version vorkamen.
• Incomplete (unvollständig): der Fehlerbericht enthält nicht genügend Informationen, um das Problem zu identifizieren oder nachstellen zu können. Wenn niemand anderes ein ähnliches Problem meldet, wird dieser Bericht nach einiger Zeit als "Invalid" markiert werden.
• Invalid (gegenstandslos): die Ursache dieses Problems liegt nicht bei Inkscape, oder die Person, die den Fehler gemeldet hat, hat nicht auf Nachfragen nach weiteren Informationen geantwortet.
• Won't Fix (wird nicht behoben): ein Problem, das in Inkscape nie behoben werden wird, da es sich z.B. um eine bewusste Design-Entscheidung handelt, oder eine bestimmte Funktion z.B. nicht in den Programmumfang passt. Mögliche Beispiele hierfür wären die Bitte, Funktionen zur Bearbeitung von Audio-Aufnahmen hinzuzufügen, oder Inkscape in einer anderen Programmiersprache neu zu schreiben.

Gewichtung von Programmfehlern

Die Gewichtung eines Fehlers ("Importance"), gibt an, wie ernst das Problem ist.

• Critical (kritisch): sehr ernstzunehmendes, inkorrektes Verhalten, das die Mehrheit der Benutzer stark betreffen wird. Zum Beispiel: reproduzierbare Abstürze nach ganz normalen Aktinen, Verlust von Daten im Dokument, Fehler in den Dokumentdaten, schwerwiegende Funktionsverluste, das Programm lässt sich für mehrere Plattformen (Linux, OS X, Windows, andere) nicht kompilieren.
• High (hoch): ernstzunehmenes, inkorrektes Verhalten, das wahrscheinlich einen großen Anteil von Benutzern betreffen wird. Zum Beispiel: reproduzierbarer Absturz nach einer wenig gebräuchlichen Abfolge von Aktionen, Verlust anderer Nutzerdaten (z.B. Fehler in der Einstellungsdatei), die Ausgabe gehorcht nicht dem SVG-Standard, standardkonforme Dokumente werden falsch interpretiert, fehlerhafte Ausgabedateien, größere Speicherlecks, Kompilieren für eine einzige Plattform funktioniert nicht.
• Medium (mittel): mäßig problematisches, inkorrektes Verhalten, das wahrscheinlich viele Nutzer betreffen wird. Zum Beispiel: Absturz unter sehr ungewöhnlichen oder unwahrscheinlichen Umständen, die Benutzeroberfläche hält sich nicht an Standards, schlechte Qualität des Renderns, niedrige Programmgeschwindigkeit, kleinere Speicherlecks, Probleme beim Kompilieren für exotische, aber aktuelle Plattformen.
• Low (niedrig): Eigenheit oder Abweichung vom erwarteten Verhalten, die einen kleinen Teil der Nutzer betreffen könnte. Zum Beispiel: kleinere Renderfehler, unpraktische Anordnung von Schaltflächen, unpraktisches Verhalten oder Begrenztheit einer Funktion eines existierenden Befehls, niedrige Programmgeschwindigkeit bei ungewöhnlicher Verwendung des Programmes, fehlerhafte Übersetzung, Probleme beim Kompilieren für Plattformen, die nicht mehr aktuell sind.
• Wishlist (Wunschliste): Fehlen von Funktionen, wodurch einige Benutzer sich in ihrer Produktivität gestört fühlen könnten. Zum Beispiel: kein automatisches Speichern, Export in ein exotisches Dateiformat wird nicht unterstützt, kein Ziehen und Ablegen zwischen Inkscape und Word.

Tags

Mittels Tags werden Fehler in Kategorien nach betroffenem Programmteil, Plattform oder allgemeiner Funktionsgruppe in Inkscape eingeteilt. Sie sind besonders nützlich für Entwickler, die sich gerade mit einem bestimmten Teil des Codes befassen und dabei gleich mehrere Fehler auf einmal beheben möchten. Im folgenden siehst Du eine unvollständige Liste der wichtigsten Tags:

• blocker (Blockade): Ein Bug der vor einer Veröffentlichung auf jeden Fall behoben werden muss.
• crash (Absturz): Der Fehler führt zum Absturz des Programms.
• regression (Rückschritt): Etwas, das schon mal in einer älteren Version funktioniert hat, geht jetzt nicht mehr.
• linux: Das Problem tritt nur unter Linux auf.
• win32: Das Problem tritt nur unter Windows auf.
• osx: Das Problem tritt nur unter OS X auf.

Ratschläge

Das allgemeine Vorgehen beim Umgang mit Fehlerberichten ist Folgendes:

Sei höflich. Es ist nicht für jeden Benutzer einfach, unsere Webseite zu besuchen, die Seite für Fehlerberichte zu finden und dann einen Fehlerbericht zu schreiben. Wenn ein Nutzer weiß, dass sein Bericht ernst genommen und fachgerecht bearbeitet wird, wird er diesem System Respekt zollen und sich besondere Mühe geben, uns bei der Lösung des Problems zu helfen.

Schließe einen nicht-reproduzierbaren Fehler niemals, wenn noch nicht angemessen viel Mühe darin investiert worden ist, zu versuchen ihn nachzustellen. Lass ihn stattdessen ein bisschen ablagern, bevor Du ihn schließt - vielleicht gibt in der Zwischenzeit jemand anderer einen besseren Bericht in den Kommentaren ab (in einigen Fällen, in denen wir den Fehler nicht reproduzieren konnten, haben uns unsere Nutzer intensiv dabei helfen können, die Ursache einzugrenzen und das Problem zu lösen, und die Nutzer haben schließlich geprüft, ob das Problem dadurch behoben worden ist.)

Verdeutliche das Problem. Wenn Du einige Zeit benötigt hast, zu verstehen, worum es überhaupt geht, ändere die Zusammenfassung oder füge einen Kommentar hinzu, so dass diejenigen, die nach Dir diesen Fehlerbericht lesen (insbesondere die Person, die in der Lage ist den Fehler zu beheben), das Problem sofort erfassen können. Zum Beispiel könnte "bizarro scrolling bug" durch "rendering quirk when scrolling while dragging masked clone" ersetzt werden, und "Inkscape crashes in this file" durch "crash when dragging gradient stops of clone parent".

Wenn Du einen Fehler mit "Fix Committed" (behoben) abschließt, füge einen Kommentar hinzu, der aussagt in welcher Revision der Bug nicht mehr auftritt. Bugs, die nur in der Entwicklerversion aufgetreten sind und vor einer Veröffentlichung behoben worden sind, können sofort nach ihrer Behebung in der Entwicklerversion mit "Fix Released" markiert werden.

Suche immer nach ähnlichen oder gleichen Fehlerberichten, bevor Du einen Fehlerbericht einreichst. Wenn Du wählen musst, welchen Bericht Du als "Duplikat" markieren sollst und welcher gültig bleiben soll, dann sollte der ältere Bericht Priorität vor dem neueren erhalten. Ausnahmen von dieser Regel können gemacht werden, wenn der neuere Bericht wesentlich bessere Informationen enthält. Wenn es sinnvoll erscheint, füge alle relevanten Zusatzinformationen in einem Kommentar zu dem Fehlerbericht hinzu, der offen bleiben soll.