Things I hate about Trac

General

I don’t know why some projects use Trac, though it’s been chosen by some people who I respect. It frequently annoys me.

For now, I’ll restrict my rant to Trac’s bug tracker. It fails to do the basic things that bug trackers should do: Make it easy to submit a bug, and make it easy to see a list of open bugs.

  • The bug tracker comments use Wiki Formatting, meaning your comment and its formatting is very likely to be mangled. This is hateful to regular users and probably annoying to most technical users. And enjoy guessing which flavor of wiki formatting it uses. Reading the formatting documentation might not add to your enjoyment.
  • There’s no way to see the bugs that I have submitted. The “My Bugs” report is apparently a list of bugs assigned to me (if I am a developer). It’s hard to know because it’s cryptically described as “This report demonstrates the use of the automatically set $USER dynamic variable, replaced with the username of the logged in user when executed.”
  • It sends me email even for my own changes to bugs.
  • It calls bugs “tickets”. Sometimes it calls them “defects”. This makes it hard for people to easily see where to file a bug.

8 thoughts on “Things I hate about Trac”

  2. Most Trac instances I’ve interacted with didn’t send me any email about bugs I reported. I’d prefer to get email on my own changes than no email at all …

  3. People use Trac because of:

    * Wiki and SCM integration
    * the timeline view
    * Wiki formating in bug comments
    * properly calling bugs “ticket” or “defect”
    * the trac-admin program
    * the plugin system
    * the easy to read source code
    * the more pretty appearance
    * the custom query tool
    * so much more reasons

    Regarding your second point: http://trac.edgewall.org/query?status=assigned&status=new&status=reopened&reporter=%7Emurrayc&order=priority&priority=highest&priority=high&col=id&col=summary&col=priority&col=status&col=owner&col=type&col=milestone

  4. I’ll have to disagree with the ease of filing bugs. I will always post bugs for projects using Trac. It’s quick and easy with no hassle. Projects using bugzilla will often not get my bug reports, because the process gets bogged down on page 5 of 30.

    Trac is no pain for casual bug reporters. Far better than anything else I’ve seen. Although Launchpad is getting pretty nice.

  5. Came across your blog via. one of the planet feeds I subscribe to. We use trac inside our organisation for our own team and find it quite nice. I feel that the points you’ve raised are addressable easily.
    * The wiki formatting for the bug descriptions and changelog entries is a feature I find useful. Not only because formatting is easier than using pre tags but also because it allows easy cross linking to other parts of the system.
    * You can easily create a custom report to get you what you want as someone else above has pointed out.
    * Mailing is configurable.
    * The lack of consistency is perhaps a problem but this is the first time I’m seeing someone bring it up.

    It takes me about 10 seconds to file a bug (if the description is small). I find the whole thing quite convenient to use and can’t really agree with your assesment here.

  7. I’ve just started using Mantis having used trac before and if you just want flexible straight forward issue tracking its pretty good. I has hooks to some wikis.

  8. Just an afterthought regarding importance of plugins: Currently GNOME Bugzilla is stuck with Bugzilla 2.something and cannot be upgraded to shiny new Bugzilla 3.0, since GNOME Bugzilla is heavily patched and updating the patches for Bugzilla 3.0 would take too much effort. With a proper plugin system upgrades might have been much easier: You’d probably have less patches to the bug tracking application and you’d use a well defined API for accessing bug information.

Comments are closed.