Moderating the bug tracker/de

From Lazarus wiki
Jump to navigationJump to search

│ Deutsch (de) │ English (en) │ français (fr) │ português (pt) │ русский (ru) │

Dieses Dokument enthält einige Richtlinien für die Verwendung des Lazarus bug tracker. Es wurde geschrieben für zwei Gruppen:

  • Lazarus Entwickler, die versuchen werden die Bugs zu berichtigen
  • Moderatoren, die die Bearbeitung eines Issue unterstützen, in dem sie Prioritäten setzen und die Reproduzierbarkeit sicher stellen.

Wir werden den Ausdruck Lazarus Team für beide Gruppen verwenden.

Lebenszyklus eines Issue

Ein Issue kann den folgenden Status haben:

  • new: er wurde in den Bug Tracker eingegeben
  • acknowledged: das Lazarus Team hat den Issue gesehen und sein Ziel gesetzt
  • assigned: der Issue wurde einem der Lazarus Entwickler zugewiesen, der versuchen wird, ihn zu berichtigen
  • confirmed: ein Mitglied des Lazarus Teams hat den Bug dupliziert oder zugestimmt, dass das Feature implementiert werden sollte
  • resolved: die Person, der der Issue zugewiesen wurde, ist der Meinung, dass der Issue geschlossen werden kann. Dann setzt sie auch die Auflösung, zum Beispiel fixed oder not an issue.

Wie können Moderatoren die Lazarus Entwickler unterstützen

Issue akzeptieren

Ziel festlegen

Der wichtigste Schritt wenn sie einen Issue bestätigen ist, dass sie das Ziel Feld festlegen. Das Ziel Feld hilft den Lazarus Entwicklern, ihre Bugbereinigungsanstrengungen zu priorisieren. Im Allgemeinen gibt es drei Optionen: next release, 1.0 oder post 1.0. Für eine Erläuterung dieser Optionen siehe Road To 1.0#1.0 or after 1.0.

  • next release: Patches, Rückschritte (das heißt Dinge, die im aktuellen Release funktionieren, aber in der SVN Version kaputt gegangen sind) und Abstürze, die einen Datenverlust verursachen können.
  • 1.0: Lazarus 1.0 wird stabile Unterstützung für die win32 und gtk2 Schnittstelle enthalten.
  • post 1.0: andere Widget-Sets und neue Features.

Doppelte Einträge entfernen

Wenn sie einen neuen Issue anschauen, dann können sie auch Duplikate entfernen, die dadurch entstehen, dass Leute den selben Issue mehr als nur einmal einreichen. Manchmal benötigt der Bug-Tracker eine lange Zeit zur Verarbeitung des neuen Reports und der Reporter wird ungeduldig und klickt erneut auf submit. Solche Issue können gelöscht werden.

Fragen an die Mailing-Liste und Foren verweisen

Wenn ein Issue keinen Bug beschreibt, es nur eine Frage ist oder der Reporter nicht weiß, wie ein bestimmtes Feature zu benutzen ist, können sie ihn an die Mailing-Liste verweisen und/oder die Foren, um seine Frage zu stellen. Dann können sie den Issue mit der Auflösung not an issue schliessen. Wenn sie wollen können sie auch eine kurze Antwort auf die Frage geben, aber der Bug-Tracker ist da, um Bug- und Feature-Anforderungen einzugeben, nicht um Support zu bieten.

Verbindungen zu anderen Issues hinzufügen

Der Bug-Tracker unterstützt das Setzen von Verbindungen zwischen Issues.

Die schwächste Verbindung ist Related. Dies ermöglicht einfach einen Link zwischen den issues. Das kann nützlich sein, wenn sie einen issue berichtigt haben, mag es die verbundenen issues ebenfalls berichtigen.

Wenn zwei Reports die selben Issue beschreiben, dann können sie den neueren Report auf Duplicate of setzen. Der andere Report erhält einen Link zu diesem Issue mit Has duplicate.

Sie können die Parent - Child Verbindung zwischen zwei Issues benutzen um die Abhängigkeit zu beschreiben. Um den Parent-Issue zu berichtigen, muss zuerst der Child-Issue berichtigt werden. Manchmal ist es nützlich, einen (großen) Issue zu klonen und Teile davon in einem separaten Child-Issue zu beschreiben.

An den FPC Bug-Tracker verweisen

Wenn ein Bug nicht in der IDE oder der LCL ist, aber in der RTL, FCL oder dem Compiler, dann können sie den Issue zum FPC Projekt im Bug-Tracker verschieben.

Issues bestätigen

Meistens ist der erste Schritt beim Berichtigen eines Issue die Erstellung eines Beispielprogramms, das den Issue zeigt. Wie schwierig das ist, hängt von dem Aufwand ab, den der Reporter betrieben hat, als er den Report eingereicht hat. Einige liefern Testprogramme zu ihrem Report (sehr schön), einige nur einen Codeschnippsel (besser als nichts) und einige überhaupt nichts. Nicht alle Reports haben angemessene Schritte zum nachvollziehen.

Wenn es nicht klar ist im Report, können sie den Reporter bitten, die Schritte zum nachvollziehen dieses Issue zu nennen und/oder ein Testprojekt zu liefern.

Wenn es ihnen gelingt, den Issue zu reproduzieren, dann können sie den Issue auf Confirmed setzen.

Tags

Die folgende Tabelle enthält Tags, mit denen man Gruppen von Bug-Reports markiert, die nicht leicht durch andere Optionen und Beschreibungen definiert werden können.

Tag Beschreibung
gtk2 Repräsentiert alle gtk2 spezifischen Bugs und dient zur Nachverfolgung, was noch erledigt werden muss, bevor gtk2 zum Standard-Widgetset unter Linux werden kann.
Retrieved from "https://wiki.freepascal.org/index.php?title=Moderating_the_bug_tracker/de&oldid=45672"