QA/Bugzilla/Felder/Status/RESOLVED

TDF LibreOffice Document Liberation Project Community Blogs Weblate Nextcloud Redmine Ask LibreOffice Spende

• Start
• Entwicklung
• Gestaltung
• QA
• Events
• Dokumentation
• Webseite
• Lokalisierung
• Barrierefreiheit
• Marketing
• Diversität
• Wiki Hilfe

• Bug Report
• Bugs bestätigen
• Projekte
• Rückschritt Test
• Automatischer Tests
• Bibisect
• QA Treffen
• QA FAQs

Zweck dieser Seite

Diese Seite handelt vom Status RESOLVED im Status-Feld in Bugzilla. Sie soll den Zweck der vielen Status RESOLVED erklären sowie die Schritte der QA beschreiben, die zum Status RESOLVED führen.

Die Bedeutung von RESOLVED

Es gibt einen ganzen Strauß von Unter-Status für RESOLVED:

• #FIXED
• #INVALID
• #WONTFIX
• #DUPLICATE
• #WORKSFORME
• #MOVED
• #NOTABUG
• #NOTOURBUG
• #INSUFFICIENTDATA

FIXED

Der Fehler wurde durch eine bestimmte Aktion bereinigt. Daher sollten eine oder mehrere target:<LO version X.y.z> Marken im Whiteboard vorliegen. Jede davon zeigt eine Version von LibreOffice. In dieser Version kommt die Bereinigung zum Tragen.

Beispiele:

• 'Blue 1' ist auf die gleiche Farbe wie 'Sky Blue 1' gesetzt - tdf#86511
  • Whiteboard: target:4.5.0 target:4.4.0.0.beta2

Falls nicht ganz klar ist, welche Aktion welchen Fehler bereinigt hat -- wird RESOLVED WORKSFORME verwendet.

INVALID

Irgendetwas an dieser Fehlerbeschreibung passt nicht. Wenn z. Bsp. jemand die folgende Fehlerbeschreibung meldet, lösen wir sie als INVALID:

 Ich bin ein Walross

 Ich bin ein Walross und jeder soll das erfahren. Die Reproduktionsschritte essen Fisch.

Bisher haben wir den Status RESOLVED INVALID als Sammelbecken für alle möglichen Fehler verwendet, inklusive der Fehler, die mehr als ½ Jahr im Status NEEDINFO verbracht haben und die wir beiseite legen wollten. Jetzt haben wir den Status #INSUFFICIENTDATA, der für diese Art von Fehlern besser passt.

WONTFIX

Hier mag es sich zwar um einen Fehler handeln, aber der wird aus einem bestimmten Grund (der üblicherweise genauer in einem Kommentar hinterlegt wird) nicht bereinigt. Beispiele sind:

• Ein Fehler, der niemanden betrifft.

DUPLICATE

Dieser Fehler ist eine Dublette eines bereits gemeldeten Fehlers.

Dieser Status wird NICHT verwendet, wenn dieselbe Person den selben Fehler zweimal meldet, da das das unsere Statistik verfälscht. Stattdessen werden diese Duplikate als "INVALID" gekennzeichnet.

WORKSFORME

WORKSFORME wird kurz als "WFM" bezeichnet.

QA hat diesen Fehler mit den vorgesehenen Mitteln und/oder Testdokumenten getestet. Der Fehler wurde in älteren Versionen identifiziert, konnte aber in der aktuellen Version nicht mehr festgestellt werden.

die richtige Reproduktionsumgebung

Wenn der Fehler unter der selben Umgebung wie beim Fehlermelder gesichtet wird (also das selbe Betriebssystem und die selbe LibreOffice Version), dann vertrauen wir mehr im Urteil WFM. Wenn nicht die richtige Umgebung vorliegt (z. Bsp. die selbe LibreOffice Version, aber ein anderes Betriebssystem), dann wäre es wohl besser, wenn jemad anders im QA/IRC channel die selbe Umgebung hat und dieser dann das Problem lösen kann.

Die Entscheidung zum Schliessen des Fehlers als WFM ohne Rückmeldung des ursprünglichen Melders ist eine Entscheidung von Fall zu Fall. Normalerweise ist es nicht schlecht, anderen die Möglichkeit zum Ausprobieren zu geben. Das Alter der Meldung und seine letzte Bestätigung sollte in die Entscheidung mit einfliessen.

Der Grund, das ein Fehler als WFM in der ursprünglichen Umgebung eingestuft wird, kann sein, dass das Userprofil korrupt ist. Dazu sollte der Melder kontrollieren, ob LibreOffice im abgesicherten Modus und zurückgesetztem User Profil (nach Zurücksetzen) das Problem löst.

Gelöst in einer neueren Version

Wenn der Fehler im Master Zweig gelöst ist, aber nicht in einem der der aktuellen Zweige (siehe unser Release Plan), dann gilt der Fehler als bereinigt und wir markieren ihn als WFM.

• tdf#74300 - Base:Database "Position und Größe" öffnet sich nicht - es zeigt stattdessen die Umgebung an
• tdf#79289 - FILEOPEN: DOCX Größe reduziert sich auf den Rahmen und der Hintergrund wird nicht angezeigt.

Wenn wir wissen, welche Aktion das Problem bereinigt hat, können wir den Entwickler bitten, die Änderung zurückzufahren. Wenn wir das nicht wissen, müssen wir es herausfinden. Dazu können wir das Schlüsselwort bibisectRequest verwenden und im Whiteboard backportRequest:<active branch> angeben. Das sagt aus, dass wir ein "inverses" bibisect brauchen (um herauszufinden, wann der Fehler bereinigt wurde anstatt wann der Fehler eingeführt wurde).

Beispiel im Whiteboard:

 backportRequest:4.2 backportRequest:4.3

Anmerkung: Bevor jemand anders behelligt wird, sollte Bibisect selbst angestossen werden, um herauszufinden, welche Aktion den Fehler bereinigt hat!

Sobald ein Fehler auf allen aktiven LibreOffice Branches bereinigt wurde (entweder durch Rückläufer oder durch Erreichen der EOL), oder wenn ein Entwickler die Rücklaufanforderung ablehnt (über einen Kommentar im Bericht oder im gerrit), wird der backportRequest:X.y Eintrag entfernt und durch backportDenied:X.y ersetzt.

Wenn die behebende Aktion identifiziert wurde, kann der Bericht als "FIXED" oder "DUPLICATE" gekennzeichnet werden, wenn die Aktion einen Bericht schliesst, der generell das gleiche Problem beschreibt.

MOVED

Wird verwendet, wenn Bugzilla nicht der richtige Platz für den Bericht ist.

NOTABUG

Das "Problem", das vom Berichterstatter berichtet ist, ist Teil des erwarteten Verhaltens von LibreOffice. Beispiele:

• Eine Funktion arbeitet wie erwartet tdf#85643.
• Rundungsfehler aufgrund der Fliesskomma-Arithmetik auf ganzzahligen Werten - tdf#86174.

NOTOURBUG

Es gibt hier ein Problem, aber das liegt nicht an LibreOffice.

Beispiele:

• LibreOffice liest/schreibt das Dateifomat korrekt, aber eine andere Software macht das nicht tdf#81854.
• Excel hat einen lange bekannten Fehler. Sie können ihn aber wegen Abwärtskompatibilität nicht beseitigen tdf#86996.
• Es gibt Softwarebeschränkungen außerhalb unserer Kontrolle tdf#85652 redmine#845.

INSUFFICIENTDATA

Wie in einem ESC call gefordert, wurde dieser Status ins Leben gerufen, um Fehler zu kennzeichnen, die abgelehnt wurden oder bei denen wir nicht genug Informationen zur Sichtung und Bereinigung haben.

Beispiele:

• User lehnt es ab, ein privates Dokument mit irgendjemand zu teilen und daher können wir den Fehler nicht reproduzieren.
• Fehler sitzt im Status NEEDINFO seit mehr als sechs Monaten.

Begründung:

• Wir markieren gegenwärtig abgelehnte Fehler als RESOLVED WORKSFORME oder als RESOLVED INVALID. Ein zusaätzlicher Status könnte uns helfen, präziser in der Anzeige des beiseitegelegten Fehlers zu sein.
• Ein zusätzlicher Status könnte uns erlauben, diplomatischer mit schwierigen Usern umzugehen und mögliche negative Auswirkungen für "INVALID" oder "WORKS FOR ME" bei solchen Fehlern zu sein.

Benennung:

• Eine Handvoll Namen für solche Fehler können vorgeschlagen werden:
  • ABANDONED
  • INSUFFICIENT_DATA (Red Hat bugzilla)
  • EXPIRED (Launchpad)
• Der Unterstrich im Status "INSUFFICIENT_DATA" wurde gekürzt, um zu den anderen RESOLUTION Status in Bugzilla zu passen.