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 werden durch setzen von Prioritäten und Sicherstellung der Reproduzierbarkeit.

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, daß das Feature implementiert werden sollte
  • resolved: die Person, der der issue zugewiesen wurde, ist der Meinung, daß 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

Bestätigen von issues

Festlegen des Ziels

Der wichtigste Schritt wenn sie einen issue bestätigen ist, daß 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 kaputtgegangen 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.

Entfernung doppelter Einträge

Wenn sie einen neuen issue anschauen, dann können sie auch Duplikate entfernen die entstanden, weil Leute den selben issue mehr als nur einmal eingereicht haben. Manchmal benötigt der bugtracker eine lange Zeit zur Verarbeitung des neuen Reports und der Reporter wird ungeduldig und klickt erneut auf submit. Solche issues 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 beschliessen. Wenn sie wollen können sie auch eine kurze Antwort auf die Frage geben, aber der bug tracker ist da, um Bugs 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 issues 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, muß 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.

Verweisen an den FPC bug tracker

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 issues 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 Menschen liefern Testprogramme zu ihrem Report (sehr schön), einige Menschen nur einen Codeschnippsel (besser als nichts) und einige Menschen ü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 issues 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

Bellow is a table with the tags utilized to mark groups of bug reports which aren't easely defined by the other options and their description.

Tag Beschreibung
gtk2 Repräsentiert alle gtk2 spezifischen Bugs und dient zur Nachverfolgung, was noch erledigt werden muß, bevor gtk2 zum Vorgabe-Widgetset unter Linux werden kann.