Re: Bug tracker?
"Stephen J. Turnbull" <stephen(a)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-t...
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(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
--
Adrian Aichner
mailto:adrianï¼ xemacs.org
http://www.xemacs.org/
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta