Bug Tracker Design Issues

2009-11-01 00:00:00 UTC

This post details some design considerations about a simple bug tracker system. Indeed the Sup project needs a better way to track issues and is looking for a bug tracking software.

This article is cross posted to Sup mailing list and the discussion will take place there.

Finding a bug tracking system we really like seems a difficult task...

A simple question I asked me was:

"Do we really need to invent this (big) tool?"

And more and more the answer I see is that we do not need yet another big tool. Especially for a bug tracker we need recipes, protocols more than a nice interface. And generally I think we better need thinking on how to split the problem in small issues than writing the tool that tackles all of them in one go.

Again the UNIX philosophy can help us to simplify all this mess!

So we need a web interface for non technical users, great. What about a pre-formatted email explained on a single web-page for reporting bugs. This simple web-page will also have a form to fill which will send the email for them. This micro web app is really simple and does a very clear job.

So we now have issues as emails. Thus the mailing-list is our bug tracker as before. However issues are now in a proper format.

A bot will receive emails on the mailing-list and process those which are in the right format.

I think that the bot will not have a lot of information to store:

(correct me if you find something else)

Issue type, severity, priority, category, person assigned, progress status, incriminated version and platform, planned milestone/released.
Issue details, discussion, answers, attachments.

All those of the first category can be easily handled in a very flexible way either with labels, or a simple mapping: Labels (like the Google bug tracker on code.google.com): Type-Defect Priority-Critical Component-UI Mapping: type: defect priority: critical component: UI

This is very flexible because this set of labels/attributes is chosen by the project maintainer to match the complexity of the project.

I would store and manage the first category using a simple YAML file.

The bot acknowledges its updates by simply answering to the discussion.

Those of the second category can be managed using a single email discussion.

Since the discussion is central to the issue, tracking the original message-ID could be used as the unique identifier.

About the issues identifier I see two options, either we try to allocate simple integers like most of the trackers or we just keep the unique (long) identifier.

Then, optionally a simple set of HTML pages can be generated using the YAML file.

About storage of the YAML file I would simply store it in the repository. If we make the bot accessible, we just have to periodically pull from it.

I don't know yet how many issues I've forgotten, and if this design is really as simple and lightweight as I claim it to be. I look forward to your answers on that.

Simple E-Mail Delaying

2009-10-03 00:00:00 UTC

Yesterday I have finally scratch an itch that was bugging me since months. And guess what it fits in less than 40 lines of shell script!

E-Mail Driven Actions

I tend to be quite bad at managing tasks to do, however I try improve myself, and already follow two simple rules. The first one is called the "two minutes rule," it says that if one thing you have to do takes less than two minutes, then it does not worth to be delayed, you should do it now! The second rule I apply is to do tasks when it pops-up in my email client (sup).

However from time to time, I receive an email which incurs a "more than two minutes" action, that I cannot cope with now. If I keep that email in my in-box, it will keep bugging me until I either pick it up or trash it because it is now outdated.

Delaying

The feature I often wanted is to be able to delay an email-based action, without having to pick it up myself in the pool of waiting emails. More precisely I really enjoy the event based approach of email processing, it is just that some emails come at the wrong time.

In this kind of situation I would like to say, "bring me that email again in two days" or "this evening" or "2 days before " or "when in vacations" or "when back online"... This way you can keep both your in-box clean (in-box-zero) and continue to follow an event based style of reacting.

This technique can also be useful to passively distribute the answer to a question among a group on a mailing-list. If you feel not the most concerned about the question then you can say "let's wait two days," and answer something if no one took it before!

Getting Delaying Into Sup

The next point was to actually have the feature in the email client I use. However I didn't really take the time to implement this. It seemed quite easy but a bit tedious and with a bunch of design choice: Where to store reminders, how often do we check them, do we poll, do we use threads, timers...

BAM! Unix Philosophy To The Rescue

During months, instead of actually coding this not-too-complex module, I was procrastinating. However this was not vain, since I got a better idea. What if we could make this feature independent of the email client? Even better I could reuse and compose existing tools!

So, the usage is as follow: you are on a discussion, and you want to delay processing it. In sup you press '|' to pipe the current email to a given program. I have named that command email-reminder. It reads the email, extracts the Message-ID and setups a task at the given time specification. The task is simply to reply to the email using the Message-ID. The time specification is the one defined by the at(1) Unix command.

About the script

The script first extracts the Message-ID (and the Subject) of the input mail. Then it cooks up a little response email, using your email and the current date, generating a Message-ID and the In-Reply-To field. Finally it runs the at(1) command, feeding it with the time specification and a call to the $SENDMAIL or msmtp(1) command.

This little script is now published on github.