• Bugtracking

FreeBSD uses GNATS for its bugtracking system. Some people think that it is good enough for our purposes; others feel that we could do better. Feelings run rather high on the issue. This page and subsequent pages will attempt to summarize what we know so far.

What I am hoping to see here is not text of the form 'I really hate/love the one I am using', but what features about the one you are using you consider acceptable and which you consider unacceptable, and why.

Existing Bug Tracking Systems

Here is a list of ones that I know of, that are Open Source and seem to be more than just half-implemented hobby projects (we certainly do _not_ need one of those!)

• GNATS

• Bugzilla

• Mantis

• RT
• Debian bug tracking system
• Scarab
• phpBugTracker

• Whups

• there is a large list of others (somewhat Linux-centric) at http://linas.org/linux/pm.html. However, it seems to be out-of-date. (I have specifically _not_ included anything from this list which used 'basic' in its description, or for which the website was either stale or dead).

• http://roundup.sourceforge.net/

• Here is another list: http://www.daveeaton.com/scm/PMTools.html.

• To browse Freshmeat's listings for 'Bug Tracking', see http://freshmeat.net/browse/846/.

Requirements for a FreeBSD Bug Tracking System

Here is a speculative list of requirements, in rough order of importance:

• Stability: must not crash under load.
• Scalability: must scale to tens of thousands of PRs, which is what we have now. The size of the project is only going to grow.
• Compatibility: must be able to import existing database. (It would be rude to the users to say 'oh, we are just going to start over.')
  • I can't see why it would be rude? We can still maintain the old database and work on all that old PRs, and we still have them on backups, but I really can't see any reason why we shouldn't take a perfect bug tracking system just because we can't import all the old PRs... -- Anonymous
  • I concur with the above poster. I think it is much more rude to drop PRs on the floor (which we have done literally thousands of times, and which I believe is partially due to problems with the tools) than it is to have a big reset once. -- eivind
  • It should be possible to at least slurp up the description and status of all of the existing PRs. You run into problems with gnats vs. most databases in things like importing references to nonexistent users, which you can finagle by assigning all of the unknown addresses to a single global 'unknown user' entry. -- wes
  • rwatson thinks that an import of the current PRs would allow people to play around before we switch

• Security: misguided people have misused GNATS in the past, so we must be able to prevent tampering.

• Accessibility: web and email, the latter especially important for the visually impaired. Preferably, command-line too, for those used to such tools.
  • At least the tools "query-pr", "grab-pr" and "close-pr" should exist on freefall.
    • Why? Do we actually need these, or this just moving out of someone's comfort zone? -- wes
• Collaboration: Allow FreeBSD-derived projects like FreeSBIE/FreeNAS/DesktopBSD and others to share their bug reports with the mothership; i.e., have a way for them to propagate bug reports into the FreeBSD bug database and allow notifications of bug state changes to propagate back -- jkoshy
• Allow interested parties to be able to receive email when a PR matching $regex comes in (or at least provides an interface to let the existing script do it).
• Should have an export utility in case we find something better later on.
• Ability to replicate the database for local use (portsmon makes use of this, but it's preferable that ordinary users are able to get access too).
• It should go without saying that it will _not_ matter what color we paint it.