Changes

[[Category:Developers/General]]{{languages|How to report bugs}}The bug/issue tracker for Gramps is located hereat the following URL: httphttps://bugswww.gramps-project.org. It /bugsThis 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]]'''.

==Report a Bugbug==

To report a bug, you must have a login account on httphttps://bugswww.gramps-project.org/bugs/login_page.php, which is the GRAMPS Gramps bug tracker. If 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 email can you submit bugs. Your email address will be handled confidentially.

Perhaps the bug you found want to report has been submitted before. To check this, click on 'View Issues'. The top of the page is reserved to for filters, which you set. Normally the default is filters are just fine. Under these filters, there is a search box. Enter the terms best describing the bug, and click apply filter. If you have an error message, try pasting a part of the error, to see if it is logged has been reported already.

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.

Click on Report Issue, 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 Gramps version you are using. You can check this in GRAMPS Gramps by clicking in the GRAMPS Gramps program the Help menu, option About.  

#The projects with names that look like '''Gramps x.x.X''' is are where issues are reported that apply specifically to a maintenance branch (see [http://www.gramps-project.org/wiki/index.php?title=Brief_introduction_to_SVN[Brief_introduction_to_Git#Types_of_branches |Types of Branches]]). A separate project exists for each maintenance branch.#The '''Gramps Trunk''' 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 trunk master branch in Subversion Git (see [http://www.gramps-project.org/wiki/index.php?title=Brief_introduction_to_SVN[Brief_introduction_to_Git#Types_of_branches |Types of Branches]]). The There is only one "Gramps Trunk" project because there is only one trunk master branch in the Subversion Git repository.

*If the issue represents functionality that does not currently exist in GRAMPSGramps, 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 3.2.6 should be filed under the '''Gramps 3.2.X''' project.

*If the issue represents a problem with functionality that has been released only exists the master branch, or the problem exists in a the master branch, but not any stable release of codereleases, 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 2.2.10 should be filed under the '''Gramps 2.2.XTrunk''' project.

*If == Resolving bugs ==This information is for the issue represents a problem with functionality that only exists in trunk, or developers following up on the problem exists in trunk, but not any stable releases, then the issue should be filed under the '''Gramps Trunk''' projectsubmitted issues.

== Resolving The [http://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 laterThis info milestone before a previous one is for out, '''please manually adjust the target release field before marking the developers following up on bug resolved,''' otherwise the submitted issuesroadmap 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 SVN revision number hash of the commit that fixed the problem.

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 developer's developers responsibility to make sure the change has been merged into trunkthe master branch. ==Bug triage== Help the Gramps project [[Bug triage]]. ==Syntax== [http://www.mantisbt.org/ Mantis bug tracker] uses its own syntax code :* ''#'' before a bug number writes a link to the bug.* ''~'' before a comment number writes a link to the comment, same as : ''{url}#c{comment number}''.* we can try to use some HTML tags into text field, like : <code> &lt;pre&gt; &lt;/pre&gt; &lt;i&gt; &lt;/i&gt; &lt;b&gt; &lt;/b&gt;</code>  [[Category:Developers/General]][[Category:Developers/Quality Assurance]]