Re: Choice of bug tracker

[Dmitry Gutov <dmitry@gutov.dev>]

On 31/08/2023 10:18, Eli Zaretskii wrote:
>> 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.

Sounds good. Modification of issues via email is definitely supported to 
an extent, and some features could be added if missing.

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

As a very low-tech fallback, we would still have emacs-devel, or a 
separate mailing list where we could forward bug emails from users who 
don't want to register an account.

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

I've never worked on any email-related software, and this does sound 
like a job for a mailing list program.

It could be useful to bring in someone with that expertise, even if they 
only share some ideas about all that.

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

I meant tool-assisted code review. As an industry term for a (usually 
web-based) solution that allows attaching comments to parts of diffs 
(with an inline view), continuing those discussions, marking comments as 
"solved", automatic marking of them as "stale" on pushes, and so on. 
View a separate list of all commits on a branch, commit since last 
viewer, a combined diff of all commits, and etc. One characteristic of 
such interfaces is a button called "Merge pull request". Though there 
are more complex tools, e.g. IIUC Differential (another tool) works with 
more bureaucracy than that.

Of course we can read patches an comment on them without any such tools. 
Both Debbugs and Bugzilla aren't going to prevent 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?

We've known and discussed many of them over the course of a number of 
years. There is no active development for Debbugs that I know of, and 
adding all (or most, or any) of those features would really amount to 
writing a new issue tracker from scratch, which is not really our 
specialization. It doesn't sound like the best use of our time.

Even with "mumi" (Guix's Debbugs replacement that Michael has linked to) 
I hesitate to discuss any plans of extension because every new web-only 
or web-oriented, or "modern tracker"-oriented feature would not only be 
a significant job on its own, it would also be a political fight at the 
same time, one after another. And, well, I'm not a Scheme hacker anyway, 
although we know some.

By choosing any of the existing bug trackers we would adopt a set of 
existing well-understood tradeoffs wholesale, which everybody would have 
to adapt to over time. And then either adjust their workflows or build 
improvements/additional tools gradually on top of that fixed base.

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

The "minimum blood" would be mumi because from what it seems like it 
retains all the email interactions and adds some moderately better looks 
when viewed on the web on top of that. As well as faster search.

But since it has the least "familiarity" factor among all of the 
discussed solutions (and features, of course, and usability testing, and 
etc...), the ability to attract more and more diverse users and 
developers though modern tooling would correspondingly be lower.

There is a sweet spot somewhere, but I don't have any scientific 
argument for its position. Though if I try to imagine myself 10-15 years 
younger (rather difficult), the grading would most likely be Github > 
Gitlab >> Bugzilla > mumi >> Debbugs. Add a pound of salt, of course.

There should also be SourceHut on this scale, but I don't know where to 
put it.