Re: Choice of bug tracker

[Dmitry Gutov <dmitry@gutov.dev>]

On 28/08/2023 14:45, Eli Zaretskii wrote:
>> Date: Mon, 28 Aug 2023 00:15:46 +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>
>>
>> On 27/08/2023 21:46, Eli Zaretskii wrote:
>>
>>> I don't know why you decided we don't agree on the goals.  I think we
>>> do;
>>   > the list of requirements for these tools was posted, and AFAIR was
>>   > agreed upon.
>>
>> "Agreed upon" maybe in the sense that the leadership sort-of-promised to
>> seriously consider a bug tracker which would satisfy the whole list of
>> them.
> 
> That's not my position, FWIW.  I'm ready to try some less-than-perfect
> bug trackers, if the things they lack are relatively minor.
> 
> The problem from my POV was that alternatives were researched, the
> results of the research were published and discussed, the downsides
> identified, and then the process stalled, perhaps because people got
> disappointed by the deficiencies.

Last time we produced this overblown list which mixed necessities with 
nice-to-haves: https://gitlab.com/gitlab-org/gitlab/-/issues/28152

Some of the things there:

  - ReCaptcha replacement (actually seems fixed now: 
https://gitlab.com/gitlab-org/gitlab-foss/-/issues/46548#note_203922493)
  - LibreJS (we already know the JS files have satisfactory licenses; 
there was a fair amount of discussion around the assets pipeline, but no 
resolution: https://gitlab.com/gitlab-org/gitlab/-/issues/15196)

There were also a few functional things like inability to include diffs 
in Merge Request notifications which seems like a genuine omission, that 
seems easy to sell to gitlabbers, and I wouldn't mind looking into.

>> Or someone in charge could revisit the list and separate the more
>> important requirements from "less important" ones.
> 
> I'd prefer that "someone in charge" took a leap of hope, produced some
> site we could use, and let us try it and see how workable is it.  If
> that/those person(s) did a good job, and would be ready to work on
> fixing the issues reported during the initial use until we could make
> the final decision, we could have some hope of finding a better tool.
> the main challenge in this particular endeavor is that we'd need to
> use two different trackers in parallel, at least for some time, so
> some solution for syncing them would be in order.

Regarding "workability", we have EMBA for people to try out. It's been 
there for several years. Unless Gitlab is crossed out from the list of 
contestants already.

There is an online demo for Bugzilla. I'm not sure if we need a 
dedicated one, but if yes, that could also be arranged.

>>> Please don't exaggerate and don't consider this a zero-sum game.  We
>>> want tools that facilitate feedback, but their primary goal is to
>>> allow development and maintenance of Emacs.  That should be a
>>> no-brainer, and I'm frankly astonished this is something that needs to
>>> be argued about.  What would be the purpose of collecting user
>>> feedback and communicating with users if we cannot efficiently apply
>>> that to development and maintenance??
>>
>> We could apply that information less efficiently, I guess? Though
>> whether it's more or less would strongly depend on individual habits.
> 
> The crucial (for me) question is: how much less efficiently?  With the
> current mail-based flows, reviewing a patch is a snap, and applying a
> patch takes mere seconds, even if I need to fix the commit message.
> If seconds become minutes, it would be bad for productivity, and
> eventually bad for our development rate.

I don't see how they become minutes (even browser web pages don't take 
this long to load), and it's a matter of habit. Anyway, both Gitlab and 
Bugzilla have means of interacting through email. Any serious omissions 
can be looked into as well (also see (*)).

>>>   It also means the instructions about how to install the
>>> relevant grammars would not have been in NEWS, so users would need to
>>> discover that by themselves.
>>
>> We could have another NEWS file for ELPA, annotated with timestamps
>> and/or Emacs versions as well. A common NEWS feed is easy enough to do
>> for the whole ELPA as well.
> 
> There would be no motivation for that.  Fact is we don't have such a
> file now, and there are good reasons for that.

We could also have an entry in Emacs 29's NEWS specifically about the 
new ts major modes that have just been added to ELPA. Since they 
wouldn't work with earlier versions of Emacs anyway, that seems appropriate.

>>> And the command we added to treesit.el
>>> for installing the grammars would be missing as well.  Not to mention
>>> the documentation in the user manual.
>>
>> I think treesit.el (since it's inseparable from treesit.c) would still
>> be in the core. Along with all its manual entries.
> 
> But the motivation to support unbundled packages would be gone.  I'
> for example, would not insist on having such a command if it supports
> only 3rd-party packages.
> 
>> But ELPA packages can have their own manuals too, JFYI.
> 
> I know.  But who monitors their quality and works on improving them?

That's the thing: GNU ELPA is supposedly "part of Emacs". So that 
responsibility is ours, I guess. At least to a certain extent.

Currently it's a matter of trusting existing maintainers, which isn't 
the worst thing to do, too.

>>> I'm not sure they will be lower.
>>
>> Number of lines changed over a year?
>>
>> The above numbers are 2x and 3x above our total number of lines. And the
>> number of changed files is 15x our total.
> 
> They are also much higher than the LOC counts of the respective
> packages, so why aren't you surprised in that case?

Mozilla's line count is said to be 20M lines, and the changes were 
counted in 6M changes, 3M deletions over a year. So that checks out.

It all depends on the exact counting method, of course (whether each 
individual diffs' numbers are added, or whether the total diff over a 
year is used; I'm assuming Mozilla's report is about the latter).

>> There seems to be a fair amount of nostalgia there toward Bugzilla, in
>> that thread (apparently from people who do like mailing list driven
>> workflows for development).
> 
> I don't remember why we rejected Bugzilla (email support, maybe?).  I
> use it (admittedly, not intensely enough) when I need to report bugs
> or submit patches to GDB and Binutils, and find it quite convenient.

I suppose it was not in the list of "forges" because it only provides 
bug tracking. If we don't manage to switch to Gitlab or SourceHut, we 
can try using Bugzilla, at least. I'm not loving its "new bug" and the 
nonexistent "most recent issues/activity" pages, but it would still be 
an improvement.

(*) It does support modifying bugs over email. I just yesterday sent a 
link to the documentation to its "Inbound Email Interface" to Po Lu, 
which is a Perl script that works on the postfix MTA (maybe other too, 
IDK) being invoked through .procmail.

That discovery actually tells me two things:
1) Many/most email workflows will probably work with Bugzilla,
2) Other bug trackers/forges which have any kind of web API can be 
adapted in a similar fashion: running a script when an email is received 
is easier than implementing a new feature in Gitlab, with 
UI/settings/permissions, so if we find that Gitlab is otherwise okay but 
its capability to modify issues over email is lacking, I can volunteer 
to look into this too.

The main limitation, however, is that this design requires people to 
create accounts in the system. Even just to file new reports. We could 
have a system/bot which would create issues for anonymous users as well, 
but it's not clear how we would resolve any follow-up questions which 
usually arise.