Using the bug tracker

From Gramps
Revision as of 19:54, 27 April 2008 by Pez4brian (talk | contribs) (Resolving Bugs)
Jump to: navigation, search

The issue tracker for Gramps is located here: It allows users and developers to log new issues and track them as they progress.


In the upper right corner of the issue tracker, there is a place to select the "project" for the bugs. "Projects" are a way to categorize issues. There are three types of projects in the issue tracker.

The "Feature Requests" project is a place for recording requests for new features.

The "Gramps Trunk" project is a place for recording issues that only apply to the trunk in Subversion (see Types of Branches). The is only one "Gramps Trunk" project because there is only one trunk in the Subversion repository.

The projects with names that look like "Gramps x.x.X" is where issues are reported that apply specifically to a maintenance branch (see Types of Branches). A separate project exists for each maintenance branch.

Submitting Issues

The first step in submitting an issue on the tracker is to determine which project it belongs to.

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 2.2.10 should be filed under the "Gramps 2.2.X" project.

If the issue represents a problem with functionality that only exists in trunk, or the problem exists in trunk, but not any stable releases, then the issue should be filed under the "Gramps Trunk" project.

Resolving Bugs

In general, when resolving an issue, it is always a good idea to add a note with the SVN revision number 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 (

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 responsibility to make sure the change has been merged into trunk.