You'll like it

We promise
Everything here is my opinion. I do not speak for your employer.
June 2008
July 2008

2008-06-28 »

Weird things about git, #2: no bug tracking system

The git developers don't track bugs. If you find a bug, you can write about it on the mailing list. You might get flamed. And then probably someone will ask you to fix it yourself and send in a patch.

This is unlike almost all other open source projects. Virtually every project out there has a basic bug tracking system attached, courtesy of SourceForge or Google Code or whatever. It's a key part of the development process, right?

Well, not exactly.

I'm also following the development mailing list for Mono. It has much less traffic than git, which is weird, because at least by lines of code (and probably number of users), Mono is a way bigger project. One of the reasons for the quiet is their bug tracking system. It's a conversation killer. Like this:

Someone reports a bug on the mailing list. "Please file it in the bug tracker." "I can't figure out how to create a bugzilla account." "Do it like this." "Okay, I created the account, but I can't figure out how to file a bug." "Do it like this." "Okay, I filed the bug. Now what?" "Now hopefully someone will fix it someday! Bye!"

So people aren't supposed to discuss bugs on the mailing list, which invites the question: what are they supposed to discuss on the mailing list? Nobody really knows. So the conversation dies. And not everybody sees every bug that comes in. Which is probably good, because there are thousands of bugs filed, and as with most open source projects (and commercial ones, for that matter), most of the bugs never get fixed, because volunteers just aren't actually very interested in fixing every last one of your problems. (This isn't to say the Mono developers don't fix tons of bugs. Mono is awesome. But it seems to be a cardinal rule of bug tracking that the bug database only grows, it never gets smaller.)

Let's be honest: bug tracking sucks the joy out of software development. git developers just work on whatever scratches their itch at that particular moment. If the same question comes up too often on the mailing list, they update the documentation. If people report a bug, they quiet those people by fixing the bug (or convincing those people to fix the bug). If they feel like implementing a new feature today, then they just do. And with multiple examples of this happening every single day, it's easy and fun to subscribe, get a feel for what's happening, and join in.

When you work to a bug tracking system, you're just doing what you're told. Some poor bug tracking janitor spends hours each day shoveling bugs around inside the system and assigning them to people and prioritizing which ones go into which release. Then the developers line up and take their bugs, and work on them in sequence so that the release can go out at the pre-ordained time.

git developers just make a code freeze branch sometimes and let it simmer for a while, then release it. Junio C Hamano is the equivalent of the bug shoveler for git, except he doesn't shovel bugs: he shovels fixes. I expect that's a much more gratifying job.

Update (2008/06/30): YCombinator News has some commentary on this article.

I'm CEO at Tailscale, where we make network problems disappear.

Why would you follow me on twitter? Use RSS.

apenwarr on gmail.com