Bug tracker?

[Adrian Aichner]

"Stephen J. Turnbull" <stephen at xemacs.org> writes:

> Hans de Graaff writes:
>
>  > I've also found http://sourceforge.net/tracker/?group_id=11 (project 11
>  > on sourceforge? Nice). Obviously this has not actually been used, but it
>  > could be without any additional work.
>
> SF Tracker is what Python decided was so unbearable that they decided
> *anything* would be better.  Having decided that, they went to work on
> beating Roundup into shape, that being what they got the most serious
> volunteers to work on.
>
>  > It would be helpful to know what it is that you hate about the default
>  > organization of all trackers.
>
> In no particular order:
>
> - No provision for generating/maintaining relationships among products
>   (aka modules), files, identifiers, and keywords.
>
> - Severity is not an ordered variable; it should be set valued,
>   including such properties as "crash", "data loss", "workaround
>   available", and suchlike.

I like you list, Stephen.

Another thing I find important is a state machine to allowed status
transitions.

I just convinced myself that roundup supports this:

http://roundup.sourceforge.net/doc-1.0/customizing.html#adding-in-state-transition-control

A distinction between Resolved and Verified (or whatever we may call
it) is also important to me.

http://roundup.sourceforge.net/doc-1.0/customizing.html
has this relevant piece of information:

creator_resolution.py
    Catch attempts to set the status to "resolved" - if the assignedto
    user isn't the creator, then set the status to
    "confirm-done". Note that "classic" Roundup doesn't have that
    status, so you'll have to add it. If you don't want to though,
    it'll just use "in-progress" instead.

I like roundup more and more from reading the docs.

Adrian

>
> - Urgency is not a user or developer variable, and should be
>   suppressed unless there's a manager with authority to decide such
>   things.
>
> - The available keywords never make any sense, and there's no
>   provision for creating a thesaurus of synonym keywords.  There's
>   rarely a facility for browsing or searching keywords.
>
> - Every bug report should be treated as a query-by-example, and the
>   reporter immediately presented with a short list of bugs (maybe as
>   many as 10 at most) with the highest similarity.
>
>  > No longer true for Bugzilla 3.0 as it has email support built-in,
>
> I forget to mention I've hated bugzilla for years, I'm not sure why.
> Several of the above have something to do with it, I'm sure. :-)  Plus
> it's a big ball of Perl, so I'll have to depend on others to implement
> any changes I want.  And it seems to be the tracker of choice for big
> institutional devel organizations like Red Hat.
>
>  > The XEmacs client test will fail on all trackers, including roundup.
>
> If you define it the way Steve Baur does, yes.  However, I happen to
> have libcurl and libneon bindings in my XEmacs, so as long as the web
> interface is sane, I can use HTTP + HTML to make an XEmacs
> interface.:-)
>
> The other thing about roundup is that its architecture makes it
> eminently hackable.
>
> _______________________________________________
> XEmacs-Beta mailing list
> XEmacs-Beta at xemacs.org
> http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
>
>

-- 
Adrian Aichner
 mailto:adrian at xemacs.org
 http://www.xemacs.org/