Re: Choice of bug tracker

[Eli Zaretskii]

> Date: Wed, 30 Aug 2023 23:29:11 +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.

Here's a list of features that I think we want to preserve:

  . submit a bug report via email
  . receive bug reports and related discussions via email
  . give instructions to the tracker via email:
    - close/reopen/merge issues
    - add/remove tags from issues
    - mark a closed bug with the Emacs version where it is fixed
  . continue discussion of an issue even after it is closed

If I missed something important, Michael and Stefan, please add to
this list.

> > 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".

I think this is imperative.  An alternative would be to have Emacs
commands to let users continue discussions of an issue via some other
medium, but frankly, nothing beats email in its easiness,
pervasiveness, and the abundance of different MUAs.  There must be a
possibility to get the users involved in the discussion of bugs they
submitted, because frequently we need more info to investigate and
decide on solutions.

So if this is not trivial, perhaps we should bring someone on board to
add such facilities for us, as our special add-on to a good bug
tracker which doesn't have that OOTB.  Like savannah-hackers or people
who manage the GNU mailing lists, for example.

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

GNU mailing lists have a very efficient system for blocking spam.

> >> 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).

Bugzilla _can_ be used for patch review, albeit maybe not conveniently
enough.  And I don't think I'd like a bug tracker that doesn't allow
to review code as part of the discussion -- where else will we then do
the latter?  Maybe I just don't understand what you mean by that, but
if you do mean patch review, then how can a good bug tracker possibly
lack that??

> > 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".

If those are the main points, perhaps we should also explore the
possibility of adding them to debbugs?

> 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.

We want to test this theory, but we don't want to give up too many
useful features of the current workflow, at least from the
maintainer's POV.  The challenge is to find a way of satisfying both
kinds of needs and requirements with "minimum blood".