[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Choice of bug tracker
From: |
Dmitry Gutov |
Subject: |
Re: Choice of bug tracker |
Date: |
Fri, 1 Sep 2023 03:29:10 +0300 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 |
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.
- Re: Choice of bug tracker, (continued)
- Re: Choice of bug tracker, Dmitry Gutov, 2023/08/29
- Re: Choice of bug tracker, Eli Zaretskii, 2023/08/30
- Re: Choice of bug tracker, Dmitry Gutov, 2023/08/30
- Re: Choice of bug tracker, Eli Zaretskii, 2023/08/31
- Re: Choice of bug tracker, Michael Albinus, 2023/08/31
- Re: Choice of bug tracker, Dmitry Gutov, 2023/08/31
- RE: [External] : Re: Choice of bug tracker, Drew Adams, 2023/08/31
- Re: [External] : Re: Choice of bug tracker, Eli Zaretskii, 2023/08/31
- Re: Choice of bug tracker,
Dmitry Gutov <=
- Re: Choice of bug tracker, Stefan Kangas, 2023/08/29
- Re: Choice of bug tracker, João Távora, 2023/08/29
- Re: Choice of bug tracker, Dmitry Gutov, 2023/08/29
- Re: Choice of bug tracker, Stefan Kangas, 2023/08/30
- Re: Choice of bug tracker, Dmitry Gutov, 2023/08/30
- Re: Choice of bug tracker, Richard Stallman, 2023/08/31
- Re: Choice of bug tracker, Richard Stallman, 2023/08/30
- Re: Choice of bug tracker, Eli Zaretskii, 2023/08/31
- Re: Choice of bug tracker, Dmitry Gutov, 2023/08/31
- Re: Choice of bug tracker, Richard Stallman, 2023/08/30