mind can has mountains

I’m not one to complain (thinks: yes I am!), but I’m not a huge fan of Alexandria’s issue tracker at RubyForge. Not that I blame the developers who wrote it, or the site who provides it to us free of charge. I know that an over-complicated interface can overwhelm a bit of software like that, and someone is always going to be without their favourite feature. In fact, I once wrote a small issue tracker with Java Servlets (I called it Gawain, I may yet revive it in some form, perhaps in another language). It didn’t support half the things that the RubyForge Tracker does, but I liked it because I could always get my hands on exactly the data I was looking for and in exactly the format I wanted it.

I should clarify. For tracking a handful of bugs, maybe even a pageful, the Tracker is fine. You can see most of the status details you want in the summary list. For following up on a single bug, it’s pretty good too: it sends out notification e-mails, you can attach files, change priority…. There are a few administrative nigglesL because I came to the Alexandria project after Laurent Sansonetti left it, I’m still not on the list of developers to whom a bug can be assigned; I get two e-mails for every change on a bug I’ve been working on, one direct from the Tracker, and one from the alexandria-bugs mailing list (which also notifies me of changes to bugs I haven’t been working on). But it works okay in small scale.

The problem is when we have a few hundred open bugs, as happens when a project lies dormant for a year or two. Sorting them out - finding duplicates,  removing obsolete reports, requesting more information from poor reports - is inevitably slow because of the nature of web applications. I really want to be able to grep through the reports, assign tags to groups of them at a time, sort them according to arbitrary conditions. What I’d like is a way to take the data home with me… A few weeks ago I was almost ready to write a scraper application to scour the four Alexandria Trackers and save each complete bug report as YAML or XML. I may yet write it.

In the mean time, there’s L.C. Karssen, who’s doing the hard work of sifting out duplicates, requesting extra information, closing old reports, confirming new reports and finding new bugs - all just using the old Tracker I’ve been complaining about. And it looks very likely that he’ll be able to get us down below a single page of (50) open, relevant, real bug reports within the next few days. That should make it much easier to use the Tracker to deal with new bug reports. Thanks Lennart!

Then, of course, we’ll have to tackle the Feature Requests Tracker, and translate some of those tickets into requirements on the Alexandria Wiki.