Re: Bug tracker?

Hans de Graaff writes: 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. 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. - 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. 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. 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