Nicolas Pouillard's Blog

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.

Starting a new Blog using Blogination

2009-09-11 00:00:00 UTC

It's time for a new blog. The main non technical goal for this one is to be non-empty :)

This time, I'm gonna force myself to write new posts on a regular basis.

The intended topics would be among: theory and practice of programming languages, in particular functional ones; some system administration tips and tools; and communication services/software like emails, twitter or Google wave.

Choosing a blogging platform

I wanted a really lightweight platform, at least from the developer point of view. I've used Typo then Mephisto and they were really to heavyweight to maintain. So I wanted a system for which I can be responsible of the code in a sustainable way. Not that I couldn't fix the various issues I had with Typo and Mephisto but more that I no longer want to!

Here are the features I wanted:

Plain text
Really small code-base
Written in Haskell
Static pages
Comments
Syndication
Tagging
UTF8

After some search, there were two competitors Blogination and Whisper. However since only Blogination was written in Haskell I opted for it.

Blogination was written by Chris Done and I must say that this tool fits almost all my needs.

Of course as I will go along with adapting Blogination for my needs I will submit patches to Chris Done.

Let's go a bit deeper into the expected features:

Plain text: No RDBMS/SQL

Relying on plain text files makes the blogging code much more simpler. Indeed the blogging code only needs to read the files. All the CRUD (create, update, delete) is done with your favorite editor.

To quote William Morgan (Whisper's author):

Storing your blog entries in a RDBMS is like driving to work in the Space Shuttle.

So even if driving a Space Shuttle could be kind of cool, I don't consider RDBMS/SQL as cool in the long run.

Then it is really simple to keep track of the contents safely using a version control system, and here Darcs is a perfect match for the situation.

Small code-base

I want to acquire the control of the code almost as if I had written it. Being able to change it easily to fit my needs is of prime importance.

Written in Haskell

Because maintaining high level, well abstracted, well typed, purely functional code is a much more pleasant task to do than what one can find elsewhere.

Static pages

Static pages generated in batch makes the administration much more simpler. Moreover there is almost no scalability issues with static pages.

Tagging and UTF8

Those speak for themselves.

Comments

At the beginning no support for comments is not a problem. I think that blog comments should reuse an existing communication layer like emails.

Comments could be supported via emails like it is done in Whisper. However in the mean time that is not the main task, sending me emails will be enough.

Syndication

Some RSS support or Atom was really needed. I also like to experiment with some pubsubhub support in the future.

Syndication will be also done with twitter, since every post will be accompanied by some tweets about it, answering to these tweets will be another way to comment on each post.

Future improvements

On the list of improvements there is: A nicer design, an inspiring blog title, more features... All of these need to come, however as I said earlier the main task is to publish contents regularly and to stop keeping these thoughts for myself.