[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[sup-talk] Choosing a bug tracker for Sup

Hi,

I would like to discuss more the issue of choosing a bug tracker for sup.

(I've made a new thread for clarity)
(This is a cross post of a post[1] on my blog)

OK lets forget Ditz[2] as an option.

Note also that I would make no objection to using a traditional bug tracker.

It seems that we do not find a tool we really like.

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.

Best regards,

[1]: http://blog.nicolaspouillard.fr/entries/2009-11-01-bug-tracker-design-issues.html
[2]: http://ditz.rubyforge.org/

-- 
Nicolas Pouillard
http://nicolaspouillard.fr
_______________________________________________
sup-talk mailing list
sup-talk@rubyforge.org
http://rubyforge.org/mailman/listinfo/sup-talk