How do you track your bugs?

I have actually asked this question once before, but it was long, long time ago in the prehistoric days of April 2008. A lot of things have happened since then. So I have figured it would be a good time to revisit this thread.

So, what do you use for bug tracking these days?

Personally, I have never actually settled on a single issue tracking system. I’m rather pragmatic in these things. The few projects I have remaining on Google Code use their tracking system. One of the nice things about it is how flexible it is. The whole idea is that it uses generic tags for things like priorities, milestones and etc. It allows you to add them on the fly while editing a ticket, but it may get messy.

Google Code Issues System

Back when Google Code started I thought this was the best thing ever: simple, flexible, powerful. But then over time most of my code migrated to Github and I haven’t been using much of it.

My GitHub stuff uses the built in tracking system there. I mean, why not. It makes sense to use the integrated feature when it’s provided for you. Especially since it will usually come with some really neat integration features. For example, commit messages can reference issues by number and this will be reflected on the issues page.

Github Issues System

Here is one of my favorite features ever: closing tickets via commit message. I know that this is silly, but for some reason I get a kick out of doing it this way. Go figure. If you have never done it, try it – it’s addictive. Here is how it’s done – when someone submits a bug it is assigned a number (say #7). When you commit your code you can do this:

git commit -m "This commit fixes #7"

As soon as you push that to Github, the issue will be automatically marked as resolved. Github scans commit messages for patters like this automatically ads comments to the system, closes or reopens tickets for you. Yes, it is an insignificant and mostly pointless feature, but damn it, I love it.

This BTW is not a unique Github feature. Google Code has pretty much the same thing going. It is a feature of using an issue system that is built into your remote repository.

For my Setup Assistant project I use Lighthouse App mostly due to the fact it was really, really simple, straightforward, free and standalone app. When I first started working on Setup Assistant I used a private subversion repository, and just needed a place where I could accumulate list of bugs and feature requests. Since then, I have re-hosted the project as a private git repository on BitBucket because… Well, git. They are one of the few places on the web that offer free private repositories, which is exactly what I needed for this project.

Lighthouse App Bug Tracking

Technically I could be using the built in bug tracking feature, but Lighthouse is actually remarkably less cumbersome. That and I already have a history of over a hundred resolved bugs in there which I don’t want to lose. I would probably be more motivated to switch if Lighthouse did not have an API that is supported by BitBucket. I managed to set it up so that I can resolve issues via commit messages as well, using only slightly more complicated syntax:

git commit -m "This fixes an annoying issue. [#7 state:resolved]"

For some reason Lightouse likes them brackets, but I’m not complaining because it works well.

At work we have a mixed bag. There is a Spiceworks installation somewhere for general purpose IT garbage but that thing is quite monstrous abomination that has every feature under the sun (including an actual, built in kitchen sink performance metrics) that we don’t use, and misses some we would need. I have set up Trac for at least one internally developed app, but I also find it a bit heavy handed. When I set it up, most of the config time was spent disabling and pruning out modules I knew we would never use.

Finally, there are few places where we use Issue Tracking System (ITS) which is an app I wrote long, long time ago. It is basically a crappy, bare bones, issue tracking system bolted onto our big intranet behemoth called MARS (Monitoring, Assessment and Review – no relation to similarly named Cisco product). I originally thought that it was wickedly witty name because I could refer to it as “IT’S on MARS”. Turns out I was the only one. Most people consider that name an eye roll hazard – when I mention it they roll their eyes so hard, they could potentially fall out.

Issue Tracking System

Truth be told, the system was originally called “The Issue Tracking System” but we were explicitly instructed to drop the THE from the name. You know – like Facebook, but for different reasons.

I guess my point is that I am not married to one system.

What do you use and why? Do you have a favorite system? Do you have a least favorite one? I don’t want to make this into a poll because we just had one. So just leave me a comment instead.