TracNav

JIRA for Developers

While JIRA offers basically the same features as Bugzilla, some features are slightly different or additional:

  • For example, the life cycle of a bug is a bit different: concerning the status, it is not sufficient to change it to Resolved to prevent a bug beeing listed as open issue. A bug needs to be set to Closed afterwards. The idea behind is that a developer sets it to Resolved while a project manager reviews the fix and sets it finally to Closed. For TRex development, we do not have such a project manager, i.e. you may set it to Closed on your own or -- if you would like to have your fix tested or reviewed by other developers -- add a comment when marking as Resolved where you request for someone else to review/test and close it.
  • Before you start fixing a bug, you may choose Start Progress to let others know that you started working on an issue.
  • If you like to track your efforts spent on developing TRex, you may use the Estimate and Time Spent fields. (However, this is not mandatory.)
  • JIRA has a project planing feature (Road Map section): Bugs can be designated to be fixed in a certain future version. As soon as all bugs of version are closed, the future version is considered to be reached. Please take this planning into account when filing or fixing bugs. If you are not sure or disagree with the association of bugs to future version, change it on your own or in case of doubt discuss it on the developers mailing list.
  • In the Change Log section, JIRA supports to create Release Notes. For each version, release notes are created by listing the bugs fixed in this version. In order to be really able to use this feature for displaying our release notes, it is necessary that not only fixed bugs, but all new features/enhancements you like to be listed in the release notes are filed as New feature or Improvement into JIRA (and of course to mark them finally as closed)!
  • The issue type task will not be shown in the release notes. Thus, this type shall be used for internal changes (refactorings) and for changes to the Web site.
  • When you write an SVN commit log, you shall refer to a JIRA bug ID by simply including the bug ID (e.g. TTC-72) into the commit log. (Your are also encouraged to paste the JIRA issue summary.) JIRA will subsequently display the commit log and affected files related to a bug. The JIRA bug IDs are case sensitive: "ttc-72" for example won't be recognized neither by the commit log analyzer nor inside JIRA comments! Furthermore, note that commit logs do not show up immediately in JIRA, since JIRA checks the commit logs only periodically. If you use the latest Subclipse SVN client, this works also in the opposite direction, i.e. you may click on a JIRA bug ID in the resource history from inside Eclipse.