Re: Bug tracker choices for Emacs.

[Glenn Morris]

Karl Fogel wrote:

> So, are we happy with debbugs?

I'm not. Some of my reasons are listed here:

http://emacsbugs.donarmstrong.com/cgi-bin/pkgreport.cgi?pkg=emacsbugs.donarmstrong.com

The main problem is, it's effectively unmaintained, and the Emacs
developers have no administrative access. A move to a gnu machine that
would hopefully fix these issues has been waiting for the best part of
a year.

By the way, I have been tempted to suggest we just start using the gnu
version anyway, rather than waiting for the current database to get
moved there.

>  Here are problems that I've found discourage me from using debbugs:
>
>   - Not really operable via the web -- just read-only operations.
>     This is huge.

Not an issue for me.

>   - Does not do automatic duplicate-finding when a new bug is submitted.
>     Launchpad bugs does, and it's a real gift.

What does "automatic duplicate-finding" mean?

> (Actually, from reading the documentation, it's not clear to me how
> to handle duplicates in debbugs at all -- there doesn't seem to be a
> simple way to say "Close bug #Y because it's a duplicate of #X".

As pointed out, the merge/forcemerge commands do this.

>   - A bit Debian-centric.  See the long list of checkboxes for
>     distributions in the search form on the front page, for example.

Offered to fix this kind of thing a year ago... (Bug#750)

> Launchpad already has code for converting debbugs to Launchpad bugs, and
> we could easily leave forwarding pointers.  I don't think conversion
> costs would be a huge problem, if we chose to convert.
>
> Thoughts?


Questions I would ask of a bug tracker:

How well maintained is it? How many developers are there, and how
responsive are they to feature and problem requests?

If we want to customize the way it behaves for Emacs, is there someone
who can do this for us, or help us do it to our local copy if it's not
a change appropriate for the tracker in general? Failing that, how
easy is it for an outsider to modify the code?

Can the Emacs developers get full administrative access?

How does it handle spam? Unregistered users must be able to submit
Emacs bug reports. Therefore there will be spam. Some kind of human
moderation is required. Can this be integrated into the mail flow? The
current emacsbugs method (closing spam bugs after the fact) is a waste
of effort, and does not deal with spam added to existing bugs. The
state of emacsbugs is shameful in this regard (again, see Bug#750 as
an example).

How does it handle the CC problem? Currently, when people report a new
bug, they need to use X-Debbugs-CC rather than CC, lest each reply
create a new bug. Often, they don't know they need to do this. Hence,
bug 4065 and 4066, for example. Tracking of references/message-ids
might fix this?

If it sends out admin messages, can these be directed to a separate
mail list from the normal bug list?

Does it suppress duplicates? This may need message-id tracking.

Can it automatically subscribe the bug reporter to all followup discussion?

Does it obfuscate addresses in the web interface?

How good is the search function? The debbugs one is not great.


Your best bet is probably to just set up a test-bed for people to play
with, and see if they like it...