Changes

Jump to: navigation, search

Using the bug tracker

2,457 bytes added, 00:56, 19 January 2020
Syntax
{{languages|How to report bugs}}
The bug/issue tracker for Gramps is located at the following URL: httphttps://bugswww.gramps-project.org/bugs
This bug/issue tracker allows users and developers to log new issues and track them as they progress. Please take some time to read the issue tracker instructions below and read '''[[How to create a good bug report|how to create a good bug report]]'''. Also, have a look at '''[[Known_issues|known issues]]''' and '''[[Common_problems|common problems]]'''.
 
== Quick recommendations ==
* Be precise
* Be clear: explain how to reproduce the problem, step by step, so others can reproduce the bug, or understand the request.
* Include only one problem per report
* Include any relevant links and examples
==Report a bug==
===1. Login===
To report a bugor raise a feature request, you must have a login account on httpthe Gramps bug tracker:* Login to your account at https://gramps-project.org/bugs/login_page.php or;* Visit the following link to create a new login account: https://gramps-project.org, which is the Gramps bug tracker/bugs/signup_page.php . When you create a user account, remember that it can take up to 12 hours before a notification email is send to you. Only after clicking on the link in the confirmation email can you submit bugs. Your email address will be handled confidentially.
===2. Search existing bugs===
==== Projects ====
In the upper right corner of On the issue trackerfrom the '''Select Project''' box, there is a place use the '''Choose Project''' drop down list to select the "project" for the bugs. "Projects" are a way to categorize issues. There are three two types of projects in the issue tracker: [[File:Dropdown-Choose-Project-GrampsBugtracker.png|thumb|right|450px|Choose Project - selection list]]
#The '''Feature Requests''' project is a place for recording requests for new features.
#The '''Gramps''' project is a place for recording all issues with Gramps. ##The projects with names that look like '''Gramps x.x.X''' are where issues are reported that apply specifically to a maintenance branch (see [[Brief_introduction_to_Git#Types_of_branches|Types of Branches]]). A separate project exists for each maintenance branch.##The '''Gramps TrunkMaster''' project should only be used by developers and testers of the latest code. It is a place for recording issues that only apply to the master branch in Git (see [[Brief_introduction_to_Git#Types_of_branches|Types of Branches]]). There is only one "Gramps TrunkMaster" project because there is only one master branch in the Git repository.
==== How to proceed ====
*If the issue represents functionality that does not currently exist in Gramps, then the issue should be filed under the '''Feature Requests''' project.
*If the issue represents a problem with functionality that has been released in a stable release of code, then the issue should be filed under the project that corresponds to the maintenance branch for that release. For example, a bug found in Gramps 35.21.6 0 should be filed under the '''Gramps 35.21.X0''' project.
*If the issue represents a problem with functionality that only exists the master branch, or the problem exists in the master branch, but not any stable releases, then the issue should be filed under the '''Gramps TrunkMaster''' project.
== Resolving bugs ==
This information is for the developers following up on the submitted issues.
The [httphttps://www.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 "Target Version" field fo 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 releaseshould 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 latermilestone 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 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 ChangeLog page for that project (httphttps://bugs.gramps-project.org/bugs/changelog_page.php).
Bugs in maintenance branch projects should not be marked as closed 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.
[http://www.mantisbt.org/ Mantis bug tracker] uses its own syntax code :
* ''<code>#</code>'' before a bug number writes a link to the bug.eg: ''<code>#1</code>'' becomes {{bug|1}}* ''<code>~</code>'' before a comment number writes a link to the comment, same as : ''<code>{url}#c{comment number}</code>''. eg: ''<code>~3</code>'' becomes [https://gramps-project.org/bugs/view.php?id=1#c3]* we can try to use some A [https://github.com/mantisbt/mantisbt/blob/55fb5721ea7d980557da484390db5c6003b63cd0/config_defaults_inc.php#L1979 limited set] of [https://www.w3schools.com/tags/ HTML tags into ] can be used in the text field, like : **<code> &lt;p&gt; &lt;/p&gt;</code> to define a paragraph.**<code> &lt;li&gt;</code> to defines a [https://www.w3schools.com/tags/tag_li.asp list item] used with:***<code> &lt;ul&gt;</code> unordered lists***<code> &lt;ol&gt;</code> ordered lists**<code> &lt;br&gt;</code> to insert a single line break.**<code> &lt;pre&gt; &lt;/pre&gt; </code> to add preformatted text, that is displayed in a fixed-width font, and it preserves both spaces and line breaks.**<code> &lt;i&gt; &lt;/i&gt; </code> usually displays text in ''italics''.**<code> &lt;b&gt; &lt;/b&gt;</code> shows '''bold''' text**<code> &lt;u&gt; &lt;/u&gt;</code> Underline a misspelled word**<code> &lt;em&gt; &lt;/em&gt;</code> It renders as emphasized text.**<code> &lt;strong&gt;</code> It defines important text. 
[[Category:Developers/General]]
[[Category:Developers/Quality Assurance]]

Navigation menu