Changes

Jump to: navigation, search

Using the bug tracker

1,287 bytes added, 21 January
Include addon version in the bug report
{{languages|How to report bugsUsing the bug tracker}}{{man tip|The bug/issue tracker for Gramps |is located at the following URL: <code>https://www.gramps-project.org/bugs</code>}}
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 ==
When composing a problem (bug) report for Gramps:* 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'''''{{man tip|Before you create a "Bug" report...|Composing a bug report can involve a lot of research and writing effort. Save yourself from unnecessary work.<ul><li>A solution or workaround might already exist in another bug report or in the forums.</li><li>If you connot find anything resembling your issue, ask about it in one of the forums. The community will help you solve or isolate the problem.</li></ul> }}
==Report a bug==
===1. Login===
To report a bug or raise a feature request, you must have a login account on the '''Gramps bug tracker''' ''([https://www.mantisbt.org/ powered by MantisBT])'':* [https://bugs.gramps-project.org {{man button|Login }}] to your account at https://gramps-project.org/bugs/login_page.php , or;* Visit Select [https://gramps-project.org/bugs/signup_page.php {{man button|Signup for a new account}}] or visit the following link to create a new login account: https://gramps-project.org/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.
===2Due to periodic SPAMbot activity, New Account requests might require human pre-approval. Search existing bugs===Perhaps the bug you want Be aware that this means that it might take up to report has been submitted 12 hours before. To check this, click on 'View Issues'. The top of the page is reserved for filters, which you set. Normally the default filters are just fine. Under these filters, there a confirmation email is sent when creating a search boxuser account. Enter Only after clicking on the terms best describing link in the bug, and click apply filterconfirmation email can you submit bugs. If you have an error message, try pasting a part of the error, to see if it is has been reported alreadyYour email address will be handled confidentially.
If the bug is already reported, read the bug report over, and see if you can add to the information. If so, you can leave a note with extra information to help the developers.{{-}}
===32. Submit new bugSearch wiki and existing bugs===Click on Report Issue, and enter the required information, see below on how to select the project to which the bug belongs[[File:Search box for existing bugs. Be verbose, the developers are bad at mind reading. We shall mercilessly close png|thumb|right|450px|Search Box]]Sometimes the bugs which have no meaningful information at allbehavior being observed might seem odd, such yet as #{{bug|7126}}-designed. Do not forget So the first step is to list search the Gramps version you are using. You can check this in Gramps by clicking in the Gramps program wiki to see what the Help menu, option Aboutdocumented behavior is==== Projects ====On the issue tracker from the If you'''Select Project''' boxre still not sure, use ask the '''Choose Project''' drop down list to select the "[https://forum.gramps-project" for the bugs. "Projects" are a way to categorize issuesorg/ Gramps community on Discourse. There are two types of projects in the issue tracker:]
If it still appears to be a bug, perhaps the bug you want to report has been reported before. To check this, click on [[Filehttps:Dropdown//gramps-Choose-Project-GrampsBugtrackerproject.org/bugs/view_all_bug_page.pngphp {{man button|thumbView Issues}}]. The top of the page is reserved for filters, which you set. Normally the default filters are just fine. Under these filters, there is a {{man label|rightSearch}} box. Enter the terms best describing the bug, and click {{man button|450px|Choose Project - selection list]]Apply Filter}} to search. If you have an error message, try pasting a part of the error, to see if it is has been reported already.
#The '''Feature Requests''' project is a place for recording requests for new features. #The '''Gramps''' project If the bug is a place for recording all issues with Gramps. ##The projects with names that look like '''Gramps x.x.X''' are where issues are already reported that apply specifically , read over the bug report, and see if you can add 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 Master''' project should only be used by developers and testers of the latest codeinformation. It is If so, you can leave a place for recording issues that only apply note with extra information to help the master branch in Git (see [[Brief_introduction_to_Git#Types_of_branches|Types of Branches]]). There is only one "Gramps Master" project because there is only one master branch in the Git repositorydevelopers.{{-}}
===3. Submit new bug===
[[File:Report issue buttons Gramps bugs.png|thumb|right|450px|'Report Issue' buttons.]]
Click on one of the {{man label|Report Issue}} buttons, and enter the required information, see below on how to select the project to which the bug belongs. Be verbose, the developers are bad at mind reading. We shall mercilessly close the bugs which have no meaningful information at all, such as #{{bug|7126}}. Do not forget to list the Gramps version you are using. You can check this in Gramps by clicking in the Gramps program the Help menu, option About.
{{-}}
==== How to proceed ====
[[File:Dropdown-Choose-Project-GrampsBugtracker.png|thumb|right|450px|Choose Project - selection list]]The first step in submitting an issue on the tracker is to determine which project it belongs to.  *If on the issue represents functionality that does not currently exist in Gramps, then the issue should be filed under tracker from the '''Feature RequestsSelect Project''' project. *If the issue represents a problem with functionality that has been released in a stable release of codebox, then use the issue should be filed under '''Choose Project''' drop down list to select the "project that corresponds to " for the maintenance branch for that releasebugs. For example, "Projects" are a bug found way to categorize issues. There are two types of projects in Gramps 5.1.0 should be filed under the issue tracker, '''Feature Requests''' and '''Gramps 5.1.0''' project.:
*The '''Feature Requests''' project is a place for recording requests for new features. **If the issue represents a problem with functionality that only exists the master branch, or the problem exists does not currently exist in the master branch, but not any stable releasesGramps, then the issue should be filed under the '''Gramps MasterFeature Requests''' project.
== Resolving bugs ==This information *The '''Gramps''' project is a place for recording all issues with Gramps. **If the issue represents a problem with functionality that has been released in a stable release or a problem with functionality that only exists in the developers following up on master branch, then the submitted issuesissue should be filed under the Gramps project.
The [https://gramps-project.org/bugs/roadmap_page.php roadmap page] of the * For 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" reports and "4.0.99", list bugs that we would eventually like feature requests relating to fix for the "X.Y" versionGramps Web, 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 see [httphttps://sourceforgewww.grampsweb.netorg/mailarchivehelp/message.php?msg_id=31870820| Get Help - Gramps Web]. 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 ==== Enter Issue Details ====[[File:Enter Issue Details page Gramps bugs.png|thumb|right|550px|Enter Issue Details - page]]The {{man label|Enter Issue Details}} page is always a good idea to add a note where you share with the hash of the commit that fixed the problemdevelopers what your issue or feature request is.
When resolving issues in Try and complete all the relevant sections as well as you can and be prepared to answer follow up questions if your report needs clarification. Here's a maintenance branch, one should always set the "Fixed in version" field concise guide on '''[[How to create a good bug report]]''' for Gramps which will greatly increase the version chances 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 ( https://gramps-project.org/bugs/changelog_page.php )reproducibility and thus being fixed.
Bugs in maintenance branch projects should not be marked as closed until ===== Filling out 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.page =====
==Bug triage==* Select Profile** Gramps runs on multiple operating systems, so it's important to know which operating system and version you are reporting an issue against. This is where you provide that information. MantisBT allows you store multiple profiles in your Account so that you can pick the appropriate one, which is handy if you run Gramps on different system configurations.* Product Version**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.**For recording issues that ''only'' apply to the master branch in Git (see [[Brief_introduction_to_Git#Types_of_branches|Types of Branches]]), use next un-released version e.g.: 5.3.0 as shown on the [https://gramps-project.org/bugs/roadmap_page.php| MantisBT Roadmap].* Addon Version** If you are reporting a bug in an addon, use the Plugin Manager or Enhanced Plugin Manager to find the version of the addon and include it in the report.{{-}}
Help the Gramps project [[Bug triage]].==Useful MantisBT bug tracker Syntax codes==
The following are useful [http://www.mantisbt.org/ MantisBT bug tracker] syntax codes you can use:* Using ''<code>#</code>'' before a bug number writes a link to the bug. eg: ''<code>#1</code>'' becomes {{bug|1}}* Use ''<code>@</code>'' before a user name to mention a person (note: user names with embedded spaces are not supported)* Using ''<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==Syntax==1#c3]* To link a GitHub Pull Request in the bug tracker, use p:gramps:nnnn: where nnnn is the PR number.
[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]== Limited HTML tags ===
* A [https://github.com/mantisbt/mantisbt/blob/55fb5721ea7d980557da484390db5c6003b63cd0/config_defaults_inc.php#L1979 limited set] of [https://www.w3schools.com/tags/ HTML tags] can be used in the text field:
**<code> &lt;p&gt; &lt;/p&gt;</code> to define a paragraph.
**<code> &lt;strong&gt;</code> It defines important text.
==See also==
* [[How to create a good bug report]]
* [[Known issues]]
* [[Common problems]]
* Help the Gramps project [[Bug triage]]
 
MantisBT.org reports providing user-oriented (''not'' admin) documentation
* [https://www.mantisbt.org/bugs/view.php?id=5070 0005070]: I have written [MantisBT] quick-start documentation [.doc, .pdf, .swx] if you’re interested
* [https://www.mantisbt.org/bugs/view.php?id=8939 0008939]: Lifecycle model [Visio] for a report in MantisBT
[[Category:Developers/General]]
[[Category:Developers/Quality Assurance]]
36
edits

Navigation menu