Changes

Jump to: navigation, search

Using the bug tracker

No change in size, 04:50, 12 January 2018
Resolving bugs: update links
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 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 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.

Navigation menu