Re: [sup-talk] Choosing a bug tracker for Sup

From: Tero Tilus <tero@tilus.net>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Choosing a bug tracker for Sup
Date: Mon, 02 Nov 2009 09:01:31 +0200	[thread overview]
Message-ID: <1257143690-sup-7839@tilus.net> (raw)
In-Reply-To: <1257111816-sup-4397@peray>

Requirements collected:
 - Store/track
   - Formal attributes: Issue type, severity, priority, category,
     person assigned, progress status, incriminated version and
     platform, planned milestone/released
   - Informal meta: Issue details, discussion, answers, attachments
 - Web-interface (at least for issue submission, searching and displaying)
 - Issue submission, commenting, attachments and editing attributes by email
 - Notifications by email

Nicolas Pouillard, 2009-11-01 23:52:
> OK lets forget Ditz[2] as an option.

Why?  (not that i have any reason why not, i've never used diz)

> 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.

Looks like this is a issue you have discussed in depth before.  Any
pointers to list archives?

> A simple question I asked me was:
>   "Do we really need to invent this (big) tool?"

Well... if somebody invented it for us already.  :)

> Especially for a bug tracker we need recipes, protocols more than a
> nice interface.

Now we are talking!  ...and when trying to choose a tool, we need to
think about what we need it to do for us.

I tried to pick the requirements you used.

> So we need a web interface for non technical users, great.

OK, this seems reasonable requirement.

> What about a pre-formatted email explained on a single web-page for
> reporting bugs.
...
> A bot will receive emails on the mailing-list and process those
> which are in the right format.

Requirement: Bug submission by email?
I'd say we need that.

> 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.

This is pretty traditional.  I'd still want to challenge a bit.  Why
do we need severity and priority?  What would they be used for?

> I would store and manage the first category using a simple YAML
> file.  The bot acknowledges its updates by simply answering to the
> discussion.

Requirement: Email notifications to ticket "subscribers"?
That's reasonable.

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

Requirement: Issue comments/attachments and status changes by email?

> I don't know yet how many issues I've forgotten

I can't figure out anything really necessary you would have missed.

-- 
Tero Tilus ## 050 3635 235 ## http://tero.tilus.net/
_______________________________________________
sup-talk mailing list
sup-talk@rubyforge.org
http://rubyforge.org/mailman/listinfo/sup-talk