BugTracker

Speed Dreams bug tracker

This Wiki-page is intended to provide information about possible bug trackers for Speed Dreams. Feel free to add, change or update things.

Properties

Below is a list of properties we like a bug tracker to have. The items below are not all equality important. The items are numbered to be able to discuss it. If you change something in this page, try to keep the numbering, or correct the numbers everywhere where they are used.

  1. Manage bugs (obviously): people who find a bug or want a feature should be able to file their bug report.
  2. Notifying developers:
    1. Send bug report to a (dedicated) mailing list, such that everyone who wants to can see the bug reports which are filed and can try to solve them (or comment on them). Bug report which are only known by the wrong people are not likely to be solved.
    2. Send all bug actions (such as comments) to the (dedicated) mailing list (less important then point 2).
  3. Assigning bugs and todo:
    1. Assign bugs to a specific person.
    2. Handle todo-list (more or less direct consequence of 3) Those todo-list might become a replacement for the current TODO file.
  4. Handle done-list (and produce a Changelog which we can use for a release). Maybe not the most important feature, but nice to have.
  5. Close commits with a commit. If a commit solves bug #12345, then this number should be in the commit message anyway. So it would be nice if the bug was automatically closed as a direct consequence of it.

SF.net built-in "Trackers"

Trac

In this section it is stated if and how Trac implements the properties as listed above.

  1. It is possible in Trac to create Tickets.
  2. ()
    1. In the configuration file of Trac, it is possible to set the smtp_always_bcc entry [t2a]. This will send all the bug emails to a specified email address (can thus be a mailing list). It is not sure that we can edit the .ini-file. As alternative, there are RSS-feeds, but as far I have seen they don't notify for new comments.
    2. If all actions are send to the mailing list, then also comments are send to that list.
  3. ()
    1. Possible
    2. A direct consequence of 3a.
  4. Don't know.
  5. Possible, according to [t5a]. This isn't implemented (yet) on SourceForge?: [t5b]

MantisBT

In this section it is stated if and how MantisBT implements the properties as listed above.

  1. In MantisBT, only "bugs" can be reported. But bugs have a severity field where the "feature" value can be set, among cosmetics, minor, major, blocking ... So it works also to track feature requests. When compared to Trac, the bug reporting form is richer, featuring reproductibility dedicated fields, as well as OS/Platform description.
  2. ()
    1. In the configuration file of Trac, it is possible to set the smtp_always_bcc entry [t2a]. This will send all the bug emails to a specified email address (can thus be a mailing list)
    2. If all actions are send to the mailing list, then also comments are send to that list.
  3. ()
    1. Bugs can be assigned to a user
    2. One can filter the bug table according to any bug property, like the bug status or its category.
  4. To get the Done list, one can simply filter the bug table according to the bug status (and other criteria, like a minimum date, a category, a minimum status, ...). This table can be exported to a CSV file. But it's generally too detailled as a user-friendly changelog ... needs manual rework / sumup.
  5. Not possible. Only CVS integration available for now (R1.2).

References

[t2a] http://trac.edgewall.org/wiki/0.10/TracIni
[t5a] http://www.assembla.com/spaces/Nikto_2/trac_subversion_tool
[t5b] http://sourceforge.net/apps/ideatorrent/sourceforge/ideatorrent/idea/9/

Related

Wiki: Index