Difference between revisions of "Moderating the bug tracker"

From Lazarus wiki
Jump to navigationJump to search
(14 intermediate revisions by the same user not shown)
Line 1: Line 1:
 
{{Moderating the bug tracker}}
 
{{Moderating the bug tracker}}
  
This document contains some guidelines for using the Lazarus [https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues bug tracker].  
+
This document contains some guidelines for moderating the Lazarus [https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues bug tracker].<br>
 +
Moderating the bugtracker can only be done by Lazarus developers.  
  
== Life cycle of an issue ==
+
== Referring questions to the mailing list and forums ==
An issue can have the following states:
+
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 close the isse and optionally add the label "Resolution: not a bug" to the report. If you wish, you can provide a short answer to his question, but the bug tracker is for entering bugs and feature requests, not for providing support.
* Open, but no assignee(s).
 
* Open and 1 or more assignees: the issue has been assigned to one or more Lazarus developers, who will try to fix/implement it.
 
* The issue has a label "Status: Confirmed": a member of the Lazarus team has duplicated the bug or agrees that the feature should be implemented.
 
* The issue has a label "Status: Feedback": the reporter should provide feedback to answer any questions posed by the Lazarus team, or to confirm that the issue is fixed satisfactorily.
 
* Closed: the assignee has closed (and presumably fixed or dismissed) the issue. The issue can also be closed by the original reporter, if the issue was fixed (or the proposal revoked).
 
 
 
== Acknowledging issues ==
 
=== Setting a Milestone ===
 
ToDo: descibe the policy on this in GitLab.
 
 
 
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 minor release''' (e.g. 1.6.2), '''post next major release''' (e.g. 1.8) or '''post next major release''' (e.g. post 1.8). For an explanation of these options, see [[Road To 1.0#1.0 or after 1.0]].
 
 
 
* next minor 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.
 
* next major release: improvements, major design changes, new features.
 
* post next major release: things that are not likely to be fixed or incuded in the next major release (e.g. new widgetset).
 
  
=== Removing duplicate entries ===
+
== Removing duplicate entries ==
 
When looking at a 'new' issue, you may need to remove duplicates that have arisen because people submitted the same issue more than once. Such 'issues' should be closed and a relationship "Duplicate" should be added, optionally a label "Resolution: Duplicate" could be added.
 
When looking at a 'new' issue, you may need to remove duplicates that have arisen because people submitted the same issue more than once. Such 'issues' should be closed and a relationship "Duplicate" should be added, optionally a label "Resolution: Duplicate" could be added.
  
=== Referring questions to the mailing list and forums ===
+
== Adding relations to other issues ==
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 close the isse and optionally add the label "Resolution: not a bug" to the report. If you wish, you can provide a short answer to his question, but the bug tracker is for entering bugs and feature requests, not for providing support.
 
 
 
=== Adding relations to other issues ===
 
 
The bug tracker supports setting relations between issues.  
 
The bug tracker supports setting relations between issues.  
  
Line 34: Line 17:
 
If two reports decribe the same issue, then you can set '''Duplicate of''' to the newest report. You can use [https://docs.gitlab.com/ee/user/project/quick_actions.html QuickACtions] to set this relationship.
 
If two reports decribe the same issue, then you can set '''Duplicate of''' to the newest report. You can use [https://docs.gitlab.com/ee/user/project/quick_actions.html QuickACtions] to set this relationship.
  
=== Moving to the patches subproject ===
+
== Moving an issue to the fpc bug tracker ==
Patches can be moved to the patches subproject. Patches are more visible there and can be managed separately from other issues.
+
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.<br>
 +
Currently only devlopers who also have developer access to the [https://gitlab.com/freepascal.org/lazarus-sandbox/lazarus_testconversion/-/issues fpc bugtracker] can do this.
  
=== Referring to the fpc bug tracker ===
+
== Moving an issue to the Lazarus-CCR 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 or components hosted on Lazarus-CCR use the Lazarus bug tracker for tracking issues. Those issues should not reside in the Lazarus project: they should be moved to the [https://gitlab.com/freepascal.org/lazarus/ccr/-/issues Lazarus CCR bug tracker].
 
Some projects or components hosted on Lazarus-CCR use the Lazarus bug tracker for tracking issues. Those issues should not reside in the Lazarus project: they should be moved to the [https://gitlab.com/freepascal.org/lazarus/ccr/-/issues Lazarus CCR bug tracker].
  
Line 46: Line 27:
 
Most of the time, the first step in fixing an issue is creating a small example program that demonstrates the issue. Reporters vary in the effort they make when submitting their initial 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 provide adequate steps for others to reproduce the supposed issue. Going to the length of adding a small, compilable example program speeds identification and resolution of the issue you have identified.
 
Most of the time, the first step in fixing an issue is creating a small example program that demonstrates the issue. Reporters vary in the effort they make when submitting their initial 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 provide adequate steps for others to reproduce the supposed issue. Going to the length of adding a small, compilable example program speeds identification and resolution of the issue you have identified.
  
If it is not clear from the bug report, you can ask the reporter to give steps to reproduce this issue and/or a test project.
+
If you manage to reproduce the issue, then you can add the label "Status: Confirmed" (you can use [https://docs.gitlab.com/ee/user/project/quick_actions.html QuickACtions] for that), or simply just say so in a comment.
  
If you manage to reproduce the issue, then you can add the label "Status: Confirmed", or simply just say so in a comment.
+
== Asking for feedback ==
 +
If it is unclear how to reproduce an issue (e.g. no code example, bug may rely on compiler options etc.) then you should ask the reporter for feedback.<br>
 +
You can use [https://docs.gitlab.com/ee/user/project/quick_actions.html QuickACtions] to add the label "Status: Feedback" and it is best to also "hail" the reporting using @reporters_username in the message.
  
 
== Assigning issues to yourself ==
 
== Assigning issues to yourself ==
Line 54: Line 37:
 
Other users, including the original reporter will then know the issue is under someones attention.<br>
 
Other users, including the original reporter will then know the issue is under someones attention.<br>
 
If it turns out that you are unable to fix the issue you have assigned to yourself, simply remove yourself as assignee.
 
If it turns out that you are unable to fix the issue you have assigned to yourself, simply remove yourself as assignee.
 +
 +
== Setting a Milestone ==
 +
When resolving (fixing) an issue (or when assigning), a developer may set a milstone.<br>
 +
This, however is not a guarantee that a fix will make it into the chosen version.
  
 
== GTK 1 issues ==
 
== GTK 1 issues ==
 
The gtk (i.e. the gtk version 1) widget set is not actively supported anymore by the Lazarus team, see [http://lists.lazarus.freepascal.org/pipermail/lazarus/2009-November/047069.html announcement]. If there is no problem when the gtk2 widget set is used instead, then the issue can be resolved with state suspended.
 
The gtk (i.e. the gtk version 1) widget set is not actively supported anymore by the Lazarus team, see [http://lists.lazarus.freepascal.org/pipermail/lazarus/2009-November/047069.html announcement]. If there is no problem when the gtk2 widget set is used instead, then the issue can be resolved with state suspended.
 
==Tags==
 
 
Below is a table with the tags utilized to mark groups of bug reports which aren't easily defined by the other options and their description.
 
 
{| class="wikitable"
 
! 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.
 
|}
 
  
 
==See also==
 
==See also==
 
* [[How do I create a bug report]] general information on submitting bugs, what should be covered in a bug report, and using the bug tracker.
 
* [[How do I create a bug report]] general information on submitting bugs, what should be covered in a bug report, and using the bug tracker.

Revision as of 12:48, 28 September 2021

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

This document contains some guidelines for moderating the Lazarus bug tracker.
Moderating the bugtracker can only be done by Lazarus developers.

Referring 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 close the isse and optionally add the label "Resolution: not a bug" to the report. If you wish, you can provide a short answer to his question, but the bug tracker is for entering bugs and feature requests, not for providing support.

Removing duplicate entries

When looking at a 'new' issue, you may need to remove duplicates that have arisen because people submitted the same issue more than once. Such 'issues' should be closed and a relationship "Duplicate" should be added, optionally a label "Resolution: Duplicate" could be added.

Adding relations to other issues

The bug tracker supports setting relations between issues.

The weakest relation is Related. This merely links the two issues. This can be useful since if you fixed one issue, it may fix the related issue(s) too. You can use QuickACtions to set a relationship.

If two reports decribe the same issue, then you can set Duplicate of to the newest report. You can use QuickACtions to set this relationship.

Moving an issue 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.
Currently only devlopers who also have developer access to the fpc bugtracker can do this.

Moving an issue to the Lazarus-CCR bug tracker

Some projects or components hosted on Lazarus-CCR use the Lazarus bug tracker for tracking issues. Those issues should not reside in the Lazarus project: they should be moved 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 demonstrates the issue. Reporters vary in the effort they make when submitting their initial 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 provide adequate steps for others to reproduce the supposed issue. Going to the length of adding a small, compilable example program speeds identification and resolution of the issue you have identified.

If you manage to reproduce the issue, then you can add the label "Status: Confirmed" (you can use QuickACtions for that), or simply just say so in a comment.

Asking for feedback

If it is unclear how to reproduce an issue (e.g. no code example, bug may rely on compiler options etc.) then you should ask the reporter for feedback.
You can use QuickACtions to add the label "Status: Feedback" and it is best to also "hail" the reporting using @reporters_username in the message.

Assigning issues to yourself

If you think you can fix a reported issue, you can assign the issue to yourself.
Other users, including the original reporter will then know the issue is under someones attention.
If it turns out that you are unable to fix the issue you have assigned to yourself, simply remove yourself as assignee.

Setting a Milestone

When resolving (fixing) an issue (or when assigning), a developer may set a milstone.
This, however is not a guarantee that a fix will make it into the chosen version.

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.

See also