Fossilized Tracs Sun, Jun 9, 2013

While working on my little project TBNdb I arrived at the point where it felt like a good idea to set up an official bug tracker. Something beyond a todo list in a text document buried somewhere. I yearned for something better than what I knew which yielded a surprising result. At least to me.

Over the years I have used Trac many times for many projects. It’s got bug tracking, report generation, integrated wiki - everything you’d want, right? And it’s great. Once it’s finally configured. And that configuration process takes years. At least that’s what it has felt like to me. Sure, the initial start takes a few seconds. Use SQLite and just run a straight tracd instance somewhere. Then it becomes a pain and soon you’ll need to hook it up to a real web server. Then what? fcgi? wsgi? Reverse proxy? Okay, now we need a way to manage users. There’s the awesome AccountManagerPlugin and now you’ve got yet another moving piece. Not using subversion like it’s 1999? You’ll need a plugin for git or hg as well. Upgrade the db to postgresql then create custom reports, macros, custom ticket fields. Now it’s perfect! Great! Then it should be easy to do it again for this next project. #facepalm

“Sure”, you say, “You’ll get that with Redmine, Jira and all the rest”

Isn’t there a better way? Part of my sysadmin brain still likes the tinkering and goofing with stuff, but less so as time goes by. These days I really like hitting the ground running. Getting things done. You know, productivity. For some reason doing things like configuring my OS, messing with ticketing systems, or adjusting themes all feels like treading water. Necessary for life, but not getting me anywhere.

So… I pull open my stuff to try document which has been fermenting for years and has enough stuff to keep me busy for the remainder of my life. In it I spot the entry that had been rattling around in my brain - Fossil - version control, bug tracking, and wiki all in one, and all of them distributed. Work locally, sync globally. Sounded too good to be true. It must suck. Does it? There must be something wrong with it. Is there? I had to find out.

After downloading the single executable (yes, really one file) and testing it out with a few miscellaneous projects I had lying about it immediately felt like home. Migrations were simple thanks to hg-git (and a topic for a future post). Coming from git and hg there was no problem understanding the semantics behind the source control and the web interface for the tickets and wiki are quite intuitive. And no, I couldn’t resist messing with the theme and creating some custom reports right off the bat (initial results All too soon it was down to actual work. The initial weekend test run has been great. For smallish teams it’s hard to imagine a more complete tool.

After I spend some more time with it maybe I’ll have more to say. Possibly the best news is complete silence as I blast through my open tickets like a rock star.