Leitfaden zur Fehlerbehandlung (Bug Triaging)

Dieser Leitfaden bespricht Empfehlungen für die Fehlerbehandlung im Ruby-Fehlerverfolgungssystem.

Fehler mit reproduzierbaren Beispielen

Dies sind die besten Fehlermeldungen. Überlegen Sie zuerst, ob der gemeldete Fehler tatsächlich ein Problem ist oder ob es sich um ein erwartetes Ruby-Verhalten handelt. Wenn es sich um ein erwartetes Ruby-Verhalten handelt, aktualisieren Sie das Problem mit einer Erklärung, warum das Verhalten erwartet wird, und setzen Sie den Status auf Abgelehnt (Rejected).

Wenn der gemeldete Fehler ein tatsächlicher Fehler zu sein scheint, versuchen Sie, den Fehler mit dem Master-Branch zu reproduzieren. Wenn Sie den Fehler im Master-Branch nicht reproduzieren können, versuchen Sie, ihn in der neuesten Version des Branches zu reproduzieren, für den der Fehler gemeldet wurde. Wenn Sie den Fehler in keinem der Fälle reproduzieren können, aktualisieren Sie das Problem und geben Sie an, dass Sie den Fehler nicht reproduzieren können. Bitten Sie den Melder, ob er den Fehler mit dem Master-Branch oder einer späteren Version reproduzieren kann, und setzen Sie den Status auf Feedback.

Wenn Sie das Beispiel mit dem Master-Branch reproduzieren können, versuchen Sie herauszufinden, was das Problem verursacht. Wenn Sie sich damit wohl fühlen, versuchen Sie, einen Patch für das Problem zu erstellen, aktualisieren Sie das Problem und fügen Sie den Patch bei. Versuchen Sie herauszufinden, welcher Committer dem Problem zugewiesen werden sollte, und setzen Sie ihn als zugewiesen (assignee) und den Status auf Zugewiesen (Assigned).

Wenn Sie das Beispiel nicht mit dem Master-Branch reproduzieren können, aber das Problem in der neuesten Version des Branches reproduzieren können, dann ist der Fehler wahrscheinlich bereits behoben, aber noch nicht zurückportiert worden. Versuchen Sie herauszufinden, welcher Commit ihn behoben hat, und aktualisieren Sie das Problem mit dem Hinweis, dass das Problem behoben, aber noch nicht zurückportiert wurde. Wenn die Ruby-Version sich in der Phase der Sicherheitswartung befindet oder nicht mehr unterstützt wird, ändern Sie den Status auf Geschlossen (Closed). Diese Änderung kann ohne zusätzliche Notiz erfolgen, um das Spammen der Mailingliste zu vermeiden.

Für Probleme, die möglicherweise abwärtskompatible Änderungen erfordern oder von allgemeiner Aufmerksamkeit oder Diskussion durch die Committer profitieren könnten, sollten Sie sie als Agendapunkte für das nächste Committer-Meeting in Betracht ziehen (bugs.ruby-lang.org/issues/14770).

Absturzfehler ohne Reproduktionsbeispiele

Viele gemeldete Fehler bestehen aus wenig mehr als einem Absturzbericht, oft ohne Möglichkeit, das Problem zu reproduzieren. Diese Fehler sind schwierig zu triagieren, da sie oft nicht genügend Informationen enthalten.

Bei diesen Fehlern, wenn die Ruby-Version der Master-Branch ist oder die neueste Version für den Branch ist und der Branch sich in der normalen Wartungsphase befindet, schauen Sie sich den Backtrace an und sehen Sie, ob Sie herausfinden können, was das Problem verursachen könnte. Wenn Sie erraten können, was das Problem verursachen könnte, versuchen Sie, ein reproduzierbares Beispiel zu erstellen (dies ist im Allgemeinen ziemlich schwierig). Wenn Sie nicht erraten können, was das Problem verursachen könnte, oder selbst kein reproduzierbares Beispiel erstellen können, bitten Sie den Melder, ein reproduzierbares Beispiel bereitzustellen, und ändern Sie den Status auf Feedback.

Wenn die Ruby-Version nicht mehr aktuell ist (z. B. 2.5.0, wenn die neueste Version im Ruby 2.5-Branch 2.5.5 ist), fügen Sie dem Problem eine Notiz hinzu, in der Sie den Melder bitten, die neueste Ruby-Version für den Branch auszuprobieren und Rückmeldung zu geben, und ändern Sie den Status auf Feedback. Wenn die Ruby-Version sich in der Phase der Sicherheitswartung befindet oder nicht mehr unterstützt wird, ändern Sie den Status auf Geschlossen (Closed). Diese Änderung kann ohne zusätzliche Notiz erfolgen.

Absturzfehler mit 3rd-Party C-Erweiterungen

Wenn der Absturz innerhalb einer 3rd-Party C-Erweiterung auftritt, versuchen Sie herauszufinden, in welcher C-Erweiterung er auftritt, und fügen Sie dem Problem eine Notiz hinzu, um das Problem an diese C-Erweiterung zu melden, und setzen Sie den Status auf Problem Dritter (Third Party’s Issue).

Keine Fehlerberichte

Alle Probleme im Fehlerverfolgungssystem, die keine Problemberichte sind, sollten von "Bug" auf entweder "Feature" (neue Funktionen oder Leistungsverbesserungen) oder "Misc" (Sonstiges) geändert werden. Diese Änderung kann ohne zusätzliche Notiz erfolgen.

Veraltete Probleme

Es gibt viele veraltete Probleme, bei denen es seit Monaten oder sogar Jahren keine Updates gab. Bei veralteten Problemen im Status "Feedback", bei denen keine Rückmeldung erhalten wurde, können Sie den Status auf "Geschlossen" (Closed) ändern, ohne eine Notiz hinzuzufügen. Bei veralteten Problemen im Status "Zugewiesen" (Assigned) können Sie den zugewiesenen Entwickler kontaktieren und sehen, ob er das Problem aktualisieren kann. Wenn der zugewiesene Entwickler kein aktiver Committer mehr ist, entfernen Sie ihn als zugewiesenen Entwickler und ändern Sie den Status auf Offen (Open).