Bug Tracker Design Issues

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.