Re: Choice of bug tracker

[Dmitry Gutov]

On 30/08/2023 14:24, Eli Zaretskii wrote:
> > Date: Wed, 30 Aug 2023 03:11:21 +0300
> > Cc: philipk@posteo.net, danny@dfreeman.email, stefankangas@gmail.com,
> >   emacs-devel@gnu.org, manuel.uberti@inventati.org
> > From: Dmitry Gutov <dmitry@gutov.dev>
> >
> > >     . we must have support for features we have now on debbugs
> >
> > As a very reluctant user of Debbugs, I have say this is not a clear
> > description for me. But as mentioned previously, the main features like
> > modifying bug reports from email should either work, or are possible to
> > implement/fix in a reasonable time frame.
>
> We could produce a detailed list of capabilities that must not regress
> wrt debbugs, if that would be useful.  The number of those
> capabilities is small.

That can help.

> > The main thing I'm not sure about are bug reports from users without
> > accounts, without requiring them to make accounts before making a bug
> > report. We could even create an email address with an account which
> > would create reports under its name, but forwarding subsequent
> > correspondence on those issues back and forth seems more difficult. It's
> > like we'd have to reimplement a mailing list, basically, but not a
> > public one.
>
> I think it would be unfortunate to ask users to create an account just
> to report a bug and ask questions about it.  At least the email
> gateway should be free of this complication (for casual submitters,
> not for the developers and maintainers whom we could ask to register).

Like I said, it's feasible to set up an email gateway that is one-way. 
But juggling responses back to unregistered users and forwarding their 
emails again seems (for those discussions to be continued) like a 
full-blown mailing list software. Maybe something like that already 
exists or could be written without too many complications. I cannot 
guarantee that in advance, however. From what I see, none of the "big 
and popular" solutions have that kind of feature, even Bugzilla's 
"Inbound email gateway".

Though at their scale it's likely to result in too much spam anyway.

> > >     . we should decide which additional features are the absolute
> > >       minimum to justify the switch (those which will attract
> > >       contributors, make feedback easier, and help people who are more
> > >       used to PR-type workflow)
> >
> > FWIW, PRs/MRs can be initially disabled, if most of the heavy
> > contributors prefer to stay on the email-driven workflow.
>
> I thought that was the single most important deficiency of debbugs?

It's a feature that could make it more pleasant/familiar for certain 
developers to contribute code, and lead the discussions around such new 
code (aka code review). But I wouldn't blame a bug tracker for not being 
a code review tool. Bugzilla isn't one either: it seems that projects 
using it used something like Gerrit for code review in the past (I have 
no experience with it).

> If they aren't, then which capabilities _are_ important to have that
> we don't have on debbugs?

Just the common bug tracker stuff, mostly related to Web UI (allowing 
one to easily read and join a discussion, subscribe to it, unsubscribe, 
syntax-highlighted code snippets, linking of issues between themselves, 
links between issues and commits, closing issues from commits, assigning 
issues to specific developers, ...). Also better working search and a 
very visible page "latest active issues/discussions".

I expect a more "modern" bug tracker to result in higher volume of bug 
reports (good and bad ones, as discussed previously), reports from more 
different kinds of users, possibly resulting in faster bug reports too. 
This is just a hypothesis (that a younger user has lower patience on 
average), but it seems logical to me.