[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [sup-talk] Choosing a bug tracker for Sup
Excerpts from William Morgan's message of Mon Nov 02 15:50:08 +0100 2009:
> Nice writeup. Just brainstorming, here are the features I personally
> find vital for an issue tracker that would make me happy:
>
> 1. Web submission. The burden of creating a record should be on the
> submitter---it's not too much to ask, and it saves developer time. This
> also encourages reporters to provide relevant information like version,
> platform, Ruby version, etc. upfront, since they can be prompted for
> those data explicitly.
> 2. Developer discussion via email. This is vital. There's no way I would
> want to have a technical discussion using text boxes on a website. And
> this discussion should be attached to the issue, of course.
1,2: Same for me.
> 3. Canonicality. I want one name for a bug, and I want one URL that I
> can point people to when referring to it. That URL should have the
> entire history, including developer discussion, of the issue.
> 4. Browseability. There should be some public way of getting a view of
> all the open issues, at a minimum. (Web seems natural.) Other stuff like
> sorting by priority, attachign to releases, etc. are icing on the cake,
> but if people are going to be chipping in on development effort, or
> searching to see if other people have had this bug, they have to be able
> to browse what's out there.
3,4:
Right, I think this is part of the web-page generation tool. Which
given the YAML file will produce web-pages. The only unclear point to
me is: "how to find the archive URL for a discussion given the message-ID?"
> > 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.
>
> I want a simple one. I can remember JIRA-style "ABC-123" names and
> that's really handy sometimes.
Right, we want short issue numbers. I'm would still be a bit sad of completely
loosing the distributed property. Maybe a solution would be to allow issues
to have an optional short name. In practice it will be just temporarily,
the time the issue makes its way to the central repository, or being just a
local issue.
--
Nicolas Pouillard
http://nicolaspouillard.fr
_______________________________________________
sup-talk mailing list
sup-talk@rubyforge.org
http://rubyforge.org/mailman/listinfo/sup-talk