Difference between revisions of "Bug triage"

From Gramps
Jump to: navigation, search
(How)
m (How: '''Current version: '''{{version}}''')
 
(58 intermediate revisions by 7 users not shown)
Line 1: Line 1:
 
Help the Gramps project with bug triaging.
 
Help the Gramps project with bug triaging.
  
The bug/issue tracker for Gramps is located at the following URL: https://www.gramps-project.org/bugs
+
Fixing a bug always starts with reproducing it, and many times the developer does not succeed in that. Making that possible is the aim of triage.
  
 +
The bug/issue tracker for Gramps is located at the following URL: https://gramps-project.org/bugs
 +
 +
{{man note|Interested in volunteering|Read this page and then contact the Gramps developers mailing list and ask for [[#MantisBT_permissions|the ability to change bugs]]}}
 
==Goals of Bug Triage==
 
==Goals of Bug Triage==
 
===What===
 
===What===
Line 11: Line 14:
  
 
===How===
 
===How===
 +
[[File:Mantisbt-valid-status-states.png|thumb|right|450px|MantisBT valid Status states.<br>
 +
* "'''<span style="background:#FCBDBD">new</span>'''"<br>
 +
* "'''<span style="background:#e3b7eb">feedback</span>'''"<br>
 +
* "'''<span style="background:orange">acknowledged</span>'''"<br>
 +
* "'''<span style="background:yellow">confirmed</span>'''"<br>
 +
* "'''<span style="background:#c2dfff">assigned</span>'''"<br>
 +
* "'''<span style="background:#C9CCC4">closed</span>'''"<br>
 +
* "'''<span style="background:Lime">resolved</span>'''"]]
 +
Make sure you're using the '''current '''{{version}}''' release of Gramps, using the master branch in [[Brief_introduction_to_Git|Git]] is usually best. From a clean install of Gramps attempt to reproduce the bug that is being reported. If you cannot reproduce the bug, post a comment as such - explaining the steps you took to reproduce the bug. If you encounter a different bug, file a new bug report for that problem if one has not been filed already.
  
Make sure you're using the latest release of Gramps, using the master branch in [[Brief_introduction_to_Git|Git]] is usually best. From a clean install of Gramps attempt to reproduce the bug that is being reported. If you cannot reproduce the bug, post a comment as such - explaining the steps you took to reproduce the bug. If you encounter a different bug, file a new bug report for that problem if one has not been filed already.
+
* Read a bit of the [https://www.mantisbt.org/documentation.php documentation of MantisBT] so you know what is possible.
  
* Read a bit of the [http://www.mantisbt.org/documentation.php documentation of mantisbt] so you know what is possible.
+
* Be familiar with the supported [[Using_the_bug_tracker#Useful_Mantis_bug_tracker_Syntax_codes|Mantis bug tracker Syntax codes]]
  
* Make sure you have Gramps installed so you can test bugs and problems. Create a family tree and import the example.gramps file.
+
* Make sure you have Gramps installed so you can test bugs and problems. Create a family tree and import the [[example.gramps]] file.
 
It would be beneficial to also run the master branch version of Gramps so as to test bugs that are in the master branch only.
 
It would be beneficial to also run the master branch version of Gramps so as to test bugs that are in the master branch only.
  
* At the moment only projects Gramps 3.4, Gramps 4.2 and master are supported, so any bugs not closed or resolved in older versions must be resolved one way or the other:
+
* At the moment only projects Gramps 5.0, Gramps 5.1 and Gramps master are supported, so any bugs not closed or resolved in older versions must be resolved one way or the other:
** resolved in the meantime
+
** "'''<span style="background:Lime">resolved</span>'''" in the meantime
** does not apply anymore
+
** does not apply anymore, state why and change the status to "'''<span style="background:#C9CCC4">closed</span>'''"
** version no longer supported ([http://en.wikipedia.org/wiki/End-of-life_%28product%29 EOL] versions), try with new version
+
** version no longer supported ([https://en.wikipedia.org/wiki/End-of-life_%28product%29 EOL] versions), [[How_to_make_a_backup|backup your family trees]] and install and try with the new version
** bug/problem still present, move the bug to the correct project eg it is a feature request
+
*** See: [[Previous_releases_of_Gramps|Previous releases of Gramps]]
** too little information given, feedback wanted from reporter
+
** bug/problem still present, or move the bug to the correct project eg decide if it is a feature request?
** several issues in one bug, close it asking users to submit a ticket per issue (or rename the bug for one issue, and ask to create new ones for the other)
+
** too little information given, "'''<span style="background:#e3b7eb">feedback</span>'''" wanted from reporter
 +
** several issues in one bug, close it asking users to submit a single ticket per issue (or rename the bug for one issue, and ask to create new ones for the other),
 
** other issues...
 
** other issues...
  
 
{{man note|ALWAYS|be polite when responding to a bug ticket.}}
 
{{man note|ALWAYS|be polite when responding to a bug ticket.}}
  
* For the supported projects, the bugs must be triaged: Duplicate bugs "'''<span style="background:grey">closed</span>'''", set a better bug title so it is more clear for a developer what the bug is about, add extra information. Most important here is to try to duplicate the bug with the example.gramps file, as that is what the developer will spend a lot of time trying to do. Fixing a bug always starts with reproducing it, and many times the developer does not succeed in that. Making that possible is the aim of triage. Once a developer sees a bug in front of him, fixing it is often fast.
+
* For the supported projects, the bugs must be triaged: Duplicate bugs "'''<span style="background:#C9CCC4">closed</span>'''", set a better bug title so it is more clear for a developer what the bug is about, add extra information. Most important here is to try to duplicate the bug with the [[example.gramps]] file, as that is what the developer will spend a lot of time trying to do. Fixing a bug always starts with reproducing it, and many times the developer does not succeed in that. Making that possible is the aim of triage. Once a developer sees a bug in front of him, fixing it is often easier.
  
 
* Then there is the feature request project. These must be organised somehow. It is best you look at some of those tickets and make a suggestion on how to organize it so that the feature requests remain useful. Also giving better titles is important here, closing duplicates. Don't be afraid to close something saying users must give a better worked out request (but be polite!).
 
* Then there is the feature request project. These must be organised somehow. It is best you look at some of those tickets and make a suggestion on how to organize it so that the feature requests remain useful. Also giving better titles is important here, closing duplicates. Don't be afraid to close something saying users must give a better worked out request (but be polite!).
  
* Don't leave bugs in "'''<span style="background:pink">new</span>'''" state if they're actually no longer '''new'''.  
+
* Don't leave bugs in "'''<span style="background:#FCBDBD">new</span>'''" state if they're actually no longer '''new'''.  
  
 
* Bugs that are clearly not spam, and have enough info to start an investigation (even though they might turn out as a problem at submitter's end) should be made "'''<span style="background:orange">acknowledged</span>'''".  
 
* Bugs that are clearly not spam, and have enough info to start an investigation (even though they might turn out as a problem at submitter's end) should be made "'''<span style="background:orange">acknowledged</span>'''".  
  
 
* Those that other people are able to reproduce (or reason about their validity) should be "'''<span style="background:yellow">confirmed</span>'''".  
 
* Those that other people are able to reproduce (or reason about their validity) should be "'''<span style="background:yellow">confirmed</span>'''".  
 +
** If a feature request is valid also move it to  "'''<span style="background:yellow">confirmed</span>'''". This only confirms it's a possibility and is not a guarantee that the Gramps project will develop and include it in a future release.
  
 
* If the bug is blocked waiting for somebody's input, mark it as "'''<span style="background:#e3b7eb">feedback</span>'''".  
 
* If the bug is blocked waiting for somebody's input, mark it as "'''<span style="background:#e3b7eb">feedback</span>'''".  
  
 
* If somebody is actively working on a bug, this is best expressed as "'''<span style="background:#c2dfff">assigned</span>'''". If you stop working on a bug, please remove it from '''assigned''' state.
 
* If somebody is actively working on a bug, this is best expressed as "'''<span style="background:#c2dfff">assigned</span>'''". If you stop working on a bug, please remove it from '''assigned''' state.
 +
** If a developer has self assigned the issue and raised an associated pull request check that it includes a reference to the MantisBT issue as mentioned in the [[Committing_policies#Create_a_pull_request|Committing policies]] the pull request should be using one of the special keywords mentioned [[Committing_policies#Bug_tracker_integration|Bug tracker integration for Git Pull request.]]
 +
 +
=== Resolving bugs for developers ===
 +
This information is for the developers following up on the submitted issues.
 +
 +
The {{man label|[https://gramps-project.org/bugs/roadmap_page.php Roadmap]}}page of the bug tracker lists the bugs currently prioritized for the next releases. If you are looking for a bug to fix, this is a good place to start. Placement on the roadmap is controlled by the {{man label|"Target Version"}} field for the bug. Special "X.Y.99" phony releases, such as "3.4.99" and "4.0.99", list bugs that we would eventually like to fix for the "X.Y" version, but don't really know the milestone yet. Bugs that really should hold up a release
 +
should be on the roadmap with a real release number, and should only be moved after giving a reason or heads up on the devel list  [http://sourceforge.net/mailarchive/message.php?msg_id=31870820]. If you fix a bug scheduled for a later
 +
milestone before a previous one is out, '''please manually adjust the target release field before marking the bug resolved,''' otherwise the roadmap display will be inaccurate [http://sourceforge.net/mailarchive/message.php?msg_id=31870821].
  
==Status==
+
In general, when resolving an issue, it is always a good idea to add a note with the “commit hash” (also called the Git commit “reference” or “SHA”) of the commit that fixed the problem.
 +
 
 +
When resolving issues in a maintenance branch, one should always set the "{{man label|Fixed in version}}" field to the version of the next release that will be made from that branch. This is done so that the issue properly appears in the {{man label|[https://gramps-project.org/bugs/changelog_page.php Change Log]}} page for that project.
 +
 
 +
Bugs in maintenance branch projects should not be marked as "'''<span style="background:Lime">resolved</span>'''" until the developer has committed the change into the corresponding maintenance branch. Additionally, it is the developers responsibility to make sure the change has been merged into the master branch.
  
On ''2015-11-26'', for '''4562''' reported issues,
+
===MantisBT permissions===
*'''1333''' are '''new''', '''feedback''', '''acknowledged''', '''confirmed''' or '''assigned'''; 29.22% <br>(these can be broken down into two categories the majority of which are '''Feature Request'''s:
 
** Feature Requests: 849 ( 63.41% )
 
** Gramps(General issues): 490 ( 36.59% ) )
 
*'''1523''' have been '''resolved(fixed)'''; 33.38%
 
*'''1706''' have been '''closed'''; 37.40%
 
  
For many years, the ratio [https://gramps-project.org/bugs/summary_page.php new reports / (fixed and closed) issues], has been increasing at around '''<span style="color:red">+2</span> per day''' ...
+
If you don't have MantisBT permissions (the ability to change bugs' status from "new" to "feedback", "acknowledged","confirmed", "closed" or  "resolved"), then feel free to ask on the [[Contact#Mailing_lists|gramps-devel]] mailing list for someone to set the status for you (eg: "Could someone set bug #{{bug|1}} to "closed" please?). Once you do this enough, feel free to ask for MantisBT permissions on the same mailing list.
  
[[File:Bug_triage.png|left|thumb|1000px|Reported issues]]
+
==Status==
{{-}}
 
{{man warn|Note|As of (2015-08-25) the highest created issue number is 8862, sometime in the past 4495 issues disappeared during a mantisdb upgrade, to which a number of existing issues keep referring to.}}
 
  
==MantisBT permissions==
+
See the summary page:
 +
* https://gramps-project.org/bugs/summary_page.php
  
If you don't have MantisBT permissions (the ability to change bugs' status from Unconfirmed to New, Fixed, or Invalid), then feel free to ask on the Gramps-dev List for someone to set the status for you (eg: "Could someone set bug #{{bug|1}} to invalid please?) Once you do this enough, feel free to ask for MantisBT permissions.
+
{{man warn|Note|Sometime in the past 4495 issues disappeared during a mantisdb upgrade, to which a number of existing issues keep referring to.}}
  
 +
==See also==
 +
* [[How to create a good bug report]]
 +
* [[Known issues]]
 +
* [[Common problems]]
  
 
[[Category:Developers/Quality Assurance]]
 
[[Category:Developers/Quality Assurance]]
 
[[Category:Developers/General]]
 
[[Category:Developers/General]]

Latest revision as of 02:23, 12 March 2022

Help the Gramps project with bug triaging.

Fixing a bug always starts with reproducing it, and many times the developer does not succeed in that. Making that possible is the aim of triage.

The bug/issue tracker for Gramps is located at the following URL: https://gramps-project.org/bugs

Gramps-notes.png
Interested in volunteering

Read this page and then contact the Gramps developers mailing list and ask for the ability to change bugs

Goals of Bug Triage

What

The goal of bug triage is to make it easier for developers to do development by organizing the bug list for them. This means the developers are able to spend less time asking bug reporters what the problem is, confirming if it is still an issue in the latest master branch in Git.

Bug triage includes the reduction of open tickets, removal of stale/out of date tickets, and grouping of feature requests.

How

MantisBT valid Status states.
* "new"
* "feedback"
* "acknowledged"
* "confirmed"
* "assigned"
* "closed"
* "resolved"

Make sure you're using the current 5.1.5 release of Gramps, using the master branch in Git is usually best. From a clean install of Gramps attempt to reproduce the bug that is being reported. If you cannot reproduce the bug, post a comment as such - explaining the steps you took to reproduce the bug. If you encounter a different bug, file a new bug report for that problem if one has not been filed already.

  • Make sure you have Gramps installed so you can test bugs and problems. Create a family tree and import the example.gramps file.

It would be beneficial to also run the master branch version of Gramps so as to test bugs that are in the master branch only.

  • At the moment only projects Gramps 5.0, Gramps 5.1 and Gramps master are supported, so any bugs not closed or resolved in older versions must be resolved one way or the other:
    • "resolved" in the meantime
    • does not apply anymore, state why and change the status to "closed"
    • version no longer supported (EOL versions), backup your family trees and install and try with the new version
    • bug/problem still present, or move the bug to the correct project eg decide if it is a feature request?
    • too little information given, "feedback" wanted from reporter
    • several issues in one bug, close it asking users to submit a single ticket per issue (or rename the bug for one issue, and ask to create new ones for the other),
    • other issues...
Gramps-notes.png
ALWAYS

be polite when responding to a bug ticket.

  • For the supported projects, the bugs must be triaged: Duplicate bugs "closed", set a better bug title so it is more clear for a developer what the bug is about, add extra information. Most important here is to try to duplicate the bug with the example.gramps file, as that is what the developer will spend a lot of time trying to do. Fixing a bug always starts with reproducing it, and many times the developer does not succeed in that. Making that possible is the aim of triage. Once a developer sees a bug in front of him, fixing it is often easier.
  • Then there is the feature request project. These must be organised somehow. It is best you look at some of those tickets and make a suggestion on how to organize it so that the feature requests remain useful. Also giving better titles is important here, closing duplicates. Don't be afraid to close something saying users must give a better worked out request (but be polite!).
  • Don't leave bugs in "new" state if they're actually no longer new.
  • Bugs that are clearly not spam, and have enough info to start an investigation (even though they might turn out as a problem at submitter's end) should be made "acknowledged".
  • Those that other people are able to reproduce (or reason about their validity) should be "confirmed".
    • If a feature request is valid also move it to "confirmed". This only confirms it's a possibility and is not a guarantee that the Gramps project will develop and include it in a future release.
  • If the bug is blocked waiting for somebody's input, mark it as "feedback".
  • If somebody is actively working on a bug, this is best expressed as "assigned". If you stop working on a bug, please remove it from assigned state.

Resolving bugs for developers

This information is for the developers following up on the submitted issues.

The Roadmappage of the bug tracker lists the bugs currently prioritized for the next releases. If you are looking for a bug to fix, this is a good place to start. Placement on the roadmap is controlled by the "Target Version" field for the bug. Special "X.Y.99" phony releases, such as "3.4.99" and "4.0.99", list bugs that we would eventually like to fix for the "X.Y" version, but don't really know the milestone yet. Bugs that really should hold up a release should be on the roadmap with a real release number, and should only be moved after giving a reason or heads up on the devel list [1]. If you fix a bug scheduled for a later milestone before a previous one is out, please manually adjust the target release field before marking the bug resolved, otherwise the roadmap display will be inaccurate [2].

In general, when resolving an issue, it is always a good idea to add a note with the “commit hash” (also called the Git commit “reference” or “SHA”) of the commit that fixed the problem.

When resolving issues in a maintenance branch, one should always set the "Fixed in version" field to the version of the next release that will be made from that branch. This is done so that the issue properly appears in the Change Log page for that project.

Bugs in maintenance branch projects should not be marked as "resolved" until the developer has committed the change into the corresponding maintenance branch. Additionally, it is the developers responsibility to make sure the change has been merged into the master branch.

MantisBT permissions

If you don't have MantisBT permissions (the ability to change bugs' status from "new" to "feedback", "acknowledged","confirmed", "closed" or "resolved"), then feel free to ask on the gramps-devel mailing list for someone to set the status for you (eg: "Could someone set bug #1 to "closed" please?). Once you do this enough, feel free to ask for MantisBT permissions on the same mailing list.

Status

See the summary page:

Gnome-important.png
Note

Sometime in the past 4495 issues disappeared during a mantisdb upgrade, to which a number of existing issues keep referring to.

See also