Difference between revisions of "Moderating the bug tracker"

From Free Pascal wiki
(Adding relations with other issues)
m (Life cycle of an issue)
Line 10: Line 10:
 
* new: it has entered in the bug tracker
 
* new: it has entered in the bug tracker
 
* acknowledged: the Lazarus team has seen the issue and has set its target
 
* acknowledged: the Lazarus team has seen the issue and has set its target
* assigned: the issue has been assigned to a lazarus developer, who will try to fix it
+
* assigned: the issue has been assigned to a Lazarus developer, who will try to fix it
 
* confirmed: a member of the Lazarus team has duplicated the bug or agrees that the feature should be implemented
 
* confirmed: a member of the Lazarus team has duplicated the bug or agrees that the feature should be implemented
* resolved: the person to who the issue was assigned thinks the issue can be closed. Then he also sets the resolution, for example '''fixed''' or '''not an issue'''.
+
* resolved: the person to whom the issue was assigned thinks the issue can be closed. Then he also sets the resolution, for example '''fixed''' or '''not an issue'''.
 
* closed: the reporter tested the fix and agrees with the fix. Periodically resolved issues that have not been closed by the reporter, will be a closed by the bug tracker administrator.
 
* closed: the reporter tested the fix and agrees with the fix. Periodically resolved issues that have not been closed by the reporter, will be a closed by the bug tracker administrator.
  

Revision as of 16:55, 26 December 2010

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

This document contains some guidelines for using the Lazarus bug tracker. This document is written for two groups:

  • lazarus developers, who will try to fix bugs
  • moderators, who will support the handling of issue by prioritizing them and making sure that they reproduceable.

We will use the term Lazarus team for both groups.

Life cycle of an issue

An issue can have the following states:

  • new: it has entered in the bug tracker
  • acknowledged: the Lazarus team has seen the issue and has set its target
  • assigned: the issue has been assigned to a Lazarus developer, who will try to fix it
  • confirmed: a member of the Lazarus team has duplicated the bug or agrees that the feature should be implemented
  • resolved: the person to whom the issue was assigned thinks the issue can be closed. Then he also sets the resolution, for example fixed or not an issue.
  • closed: the reporter tested the fix and agrees with the fix. Periodically resolved issues that have not been closed by the reporter, will be a closed by the bug tracker administrator.

How can moderators support the Lazarus developers

Acknowledging issues

Setting the target

The most important step when you acknowledge an issue, is that you set the target field. The target field helps the lazarus developers to prioritize their bug fixing effort. Generally there are three options: next release, 1.0 or post 1.0. For an explanation of these options, see Road To 1.0#1.0 or after 1.0.

  • next release: patches, regressions (i.e. things that work in the current release, but got broken in the svn version) and crashes that can cause data loss.
  • 1.0: Lazarus 1.0 will contain stable support for win32 and gtk2 interface.
  • post 1.0: other widget sets and new features.

There are two fields for the target:

  • LazTarget, which can be used to select issues for several (sub-)projects at once, for example Lazarus, Lazarus/packages and Lazarus/patches.
  • Target version, which is used by the road map.

Removing duplicate entries

When looking at new issue, you can also remove duplicated that are caused, because people submitted the same issue more than once. Sometimes the bugtracker takes a long time to process the new report and the reporter gets impatients and clicks on submit again. Those issues can be deleted.

Refering questions to the mailing list and forums

If an issue doesn't describe a bug, but is only question or the reporter doesn't know how to use certain feature, you can refer him to the mailing list and/or the forums to ask his question. Then you can resolve the issue with resolution "not an issue". If you wish you can provide a short answer to the question, but the bug tracker is to enter bugs and feature request, not to provide support.

Adding relations with other issues

The bug tracker supports setting relations between issues.

The weakest relation is Related. This gives just a link between the issues. This can be useful, if you fixed one issue, it may fix the related issues too.

If two reports decribe the same issues, then you can set Duplicate of to the newest report. The other report gets a link to that issue with Has duplicate.

You can use the Parent - Child relation between two issues to describe dependency. In order to fix the Parent issue, first the Child issue must be fixed. Sometimes it is usefull to clone a (big) issue and describe part of it in a seperate Child issue.

Moving to the patches subproject

Patches can be moved to the patches subproject. There patches are more visible and can be managed separately from the other issues.

Referring to the fpc bug tracker

If a bug is not in the IDE or the LCL, but in the RTL, FCL or the compiler, you can move the issue to the FPC project in the bug tracker.

Referring to the Lazarus-CCR bug tracker

Some projects / components hosted on Lazarus-CCR use the Lazarus bug tracker for tracking issues. Those issues should not reside in the Lazarus project: you can move them to the Lazarus CCR bug tracker.

Confirming issues

Most of the time, the first step in fixing an issue, is creating a small example program that shows the issue. How difficult this is depends on the effort the reporter has made, when he submitted the report. Some people add test programs to their report (very nice), some people only add a code snippet (better than nothing) and some people add nothing at all. Not all reports have adequate steps to reproduce.

If it is not clear from the report, you can ask the reporter the give steps to reproduce this issue and/or a test project.

If you manage to reproduce the issue, then you can set the issue to Confirmed.

GTK 1 issues

The gtk (i.e. the gtk version 1) widget set is not actively supported anymore by the Lazarus team, see announcement. If there is no problem when the gtk2 widget set is used instead, then the issue can be resolved with state suspended.

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 Description
gtk2 Represents all gtk2 specific bugs and is used to track what needs to be fixed before gtk2 becomes the default Linux widgetset.