Re: [Gaim-cabal] bug trackers

[Luke S. <lsc...@us...>]

On Mon, Aug 21, 2006 at 09:32:49PM -0400, Ethan Blanton wrote:
> Luke Schierer spake unto us the following wisdom:
> > What bug tracking software have you all interacted with?  What are
> > the pros and cons?
> 
> My analysis of both SF and bugzilla are very similar to yours.  For
> the record, however, I would take sf over bugzilla any day.
> 
> > RT: it is unfamiliar to most people.  I can interact with it via web
> > or email or command line client.  It offers a top down view of a bug,
> > vrs. SF's bottom up view.  It lets us control what users can set,
> > without confusing them.  Downside: changing things can take several
> > pages in the web interface.  it offers good filtering.  It has an
> > integratable faq tool (RTFM).  I've used it before.
> 
> What sort of changing takes several pages?  If normal interactions
> (create a bug, add a comment, close a bug) are simple, that's good
> enough ... infrequent actions are welcome to be somewhat more
> cumbersome.


http://www.bestpractical.com/images/screenshots/rt/3.0/readticket.gif

shows the basic interface for reading a bug.  There are links for
"resolve" (you do not close bugs as a developer, the submitter or (in
the case of abandoned bugs) the system must do that.) and comment in
the history and at the top of the page.

You'd use the "people" link to reassign a bug.
You'd use the "links" link to create bug dependencies or to merge
bugs.  Unmerging bugs doesn't work well when I use RT, it might have
improved.

You can directly take a bug you are viewing if you are logged in and
have access.  So to assign to yourself does not require a different
page.

the "history" link is mostly useless unless you are trying to figure
out what someone else did with a bug.  I might use it, I doubt many
other people would.

"Basics" lets you move a bug to a different queue, change the
subject, and mess with priority.  It also has some other options we
wouldn't use.

I doubt we'd use "Dates"

"People" deals with who gets emails about this bug, who owns it
(excepting the "take" option).  I'd use this.   HOPEFULLY you all
would if I mis-assign something ;-)

"links" is described above.

"jumbo" is new, it wasn't there when I used RT.  the docs say it has
all of the above, plus the comment/reply fields.

You can search for bugs, and save your search.  This is essentially
filtering the view of the bug queue.  Its alot more flexible than the
filters SF provides.

There are "comments" and "replies."  Comments are by default hidden
from the requestor/submitter.  IE when I want to ask one of you to
look at something, there's no need to email the submittor.  "replies"
are by default visible to the submitter.

You can tell it to include an article from RTFM, the faq manager, in
a reply.  This is essentially a more powerful canned responce system.

more on this at

http://wiki.bestpractical.com/index.cgi?ManualUsingWebInterface

The email interface appears to be poorly documented, and I'd have to
research this to provide examples of how to use it.  The debian
package rt3.4-clients might have some of the neccessary docs.

For users, they would just reply to the email and the system would
take care of it for them, ie reopening their bug if it was marked
STALLED (SF pending).  Similarly, it can be set to create new tickets
from mail sent to an email address.  This would have some problems,
such as spam filtering, but it would be essentially replacing having
Sean and I seeing emails in our inboxes where users ask for support
directly, with the same spam management issues I would face anyway.
It would be a merge of the various SF trackers and associated mailing
lists.

luke