16,736
edits
Changes
no edit summary
;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
{{man note|Interested in volunteering|Read this page and then contact the [https://forum.gramps-project.org/ Gramps developers mailing list forum] and ask for [[#MantisBT_permissions|the ability to change bugs]]}}
==Goals of Bug Triage==
===What===
* "'''<span style="background:#C9CCC4">closed</span>'''"<br>
* "'''<span style="background:Lime">resolved</span>'''"]]
Make sure you're using the latest '''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.
* Read a bit of the [https://www.mantisbt.org/documentation.php documentation of MantisBT] so you know what is possible.
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.02, Gramps 56.1 0 and Gramps master are supported, so any bugs not closed or resolved in older versions must be resolved one way or the other:
** "'''<span style="background:Lime">resolved</span>'''" in the meantime
** does not apply anymore, state why and change the status to "'''<span style="background:#C9CCC4">closed</span>'''"
** 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
*** See: [[Previous_releases_of_Gramps|Previous releases of Gramps]]
** bug/problem still present, or move the bug to the correct project eg decide if it is a feature request?** 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...
* 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 fo 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].
In general, when resolving an issue, it is always a good idea to add a note with the hash “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 Change Log page for that project ( {{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.
===MantisBT permissions===
If you don't have MantisBT permissions (the ability to change bugs' status from Unconfirmed "new" to New"feedback", Fixed"acknowledged", "confirmed", "closed" or Invalid "resolved"), then feel free to ask on the [[Contact#Mailing_listsOfficial|gramps-develGramps Forum]] mailing list developers section for someone to set the status for you (eg: "Could someone set bug #{{bug|1}} to invalid "closed" please?). Once you do this enough, feel free to ask for MantisBT permissions on the same mailing listGramps Forum developers section .
==Status==
* https://gramps-project.org/bugs/summary_page.php
{{man warn|Note|Sometime that sometime in the past 4495 issues disappeared during a mantisdb MantisBT database upgrade|, to which a number of existing issues keep referring to.}} ==Issues==With MantisBT:* {{bug|0012273}} "Bugtracker" Make specific permission profile for people who are only triagers
==See also==
[[Category:Developers/Quality Assurance]]
[[Category:Developers/General]]
[[Category:Troubleshooting]]