Choice of bug tracker

[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. Alas, there are none around.

I'm not sure how we could make progress without revisiting said 
requirements and our priorities.

>>> If you do a good job, and the tools are useful, they _will_ be used,
>>> and then a buy-in might be a no-brainer.  We will see when we get
>>> there.
>>
>> There is no point in me doing either, if the catching issue is how other
>> developers find it possible (or not) to work with specific tools.
> 
> Again, I don't understand how or why you arrived to that conclusion.
> I don't think it is correct.

I might very well be mistaken in my conclusion (happy to be), but it 
should be easy to see how I arrived at it.

>> Should we go through another round of listing bug trackers and voting,
>> or something?
> 
> What for?  We need tools that satisfy certain requirements, why does
> it matter how they are called?  If we find a set of tools that can
> support our requirements, at least most of the important ones, we
> could try using them, and only then it will be known whether the
> workflows are good enough and whether the features that are missing
> are critical.

The phrase "most of the important ones" gives me a bit of hope.

> And voting is absolutely the worst method of getting anything
> significant done around here.  If I used voting for decisions how to
> implement bidi, I would still be discussing this on the (now defunct)
> emacs-bidi list, instead of having a working implementation.

Voting would be one of the ways to arrive at those "only important 
requirements". It's not so bad because familiarity is helpful as well 
(as we're all aware here, all with existing habits and preferences).

Or someone in charge could revisit the list and separate the more 
important requirements from "less important" ones.

>>>> Important for allowing more people participate in the conversations.
>>>
>>> That's not the main goal of these tools, as far as the maintainers are
>>> considered.
>>
>> If collecting user feedback and communicating with users is not the main
>> goal, and reducing maintainers' workload is the priority, I guess we
>> should stop asking for more code to be contributed in Emacs.
> 
> 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.

>> At least as far as anything that can possibly live in ELPA is
>> concerned (meaning: clojure-ts-mode yes, project.el or xref no). Let
>> the developers use the trackers they are comfortable with, with
>> maximum flexibility. The proverbial "lean core".
> 
> I'm not aware that ELPA packages are forced to use debbugs.  We accept
> reports about them on debbugs, but don't enforce that, at least AFAIK.

That's what I was saying: if we encouraged the use of ELPA more, the 
issue of our common bug tracker (and whether it's good or not) would be 
a little less important. Though probably not

>> BTW, if js-ts-mode and others lived in ELPA, there wouldn't be an issue
>> of Emacs 29.1 users having ts modes incompatible with the latest
>> grammars (they'd just upgrade Elisp code over ELPA).
> 
> Not true.  Moving a mode to ELPA doesn't solve that particular problem
> (or any other one).

But it does. Makes it better, at least. Makes the solution more obvious 
to the user (I installed it from there -> there is an update -> I'll 
update it from there now).

> On the contrary: having those not bundled would
> mean users don't have an OOTB solution, and would need to invent their
> own wheels.

You can't say "on the contrary" and then go on to state something 
orthogonal.

'M-x package-install' works, there is nothing to invent. But it would be 
good if the core leads paid more attention to it and ELPA in general.

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

> 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 ELPA packages can have their own manuals too, JFYI.

> These are the immediate downsides of having a package outside of the
> core.
> 
>>>> Perhaps Lisp is denser than JavaScript or C, and et cetera, but it's
>>>> hard to argue that Emacs is more complex, or even comparable, to
>>>> Firefox.
>>>
>>> No, it isn't hard.  Compare the number of domains whose expertise we
>>> need, that's the important aspect.
>>
>> They would obviously have more.
> 
> Yeah, right.
> 
> The list of the kinds of domain expertise we need in Emacs was posted
> in the past, most of it is not needed for those other projects.

For... web browsers? They are known to be some of the most complex 
pieces of software around, these days.

>>>> And if they reached this size in 20 years rather than 40, it's
>>>> an evidence to better productivity rather than the opposite, right?
>>>
>>> They have a Web browser, that's all.
>>
>> Yeah, a program written in C/C++/Rust which contains an interpreter (and
>> multiple jit's) for a dynamic programming language and has most of its
>> interface written in it, supports user extensions in the same language,
>> support display of arbitrary files and has several related but different
>> mechanisms for guiding the visuals and the layout of said display. It
>> also supports bidi.
> 
> It's just a browser.  All the features you mention are used for Web
> browsing.

And we're talking on the mailing list for "just a text editor".

>>>> According to
>>>> https://blog.mozilla.org/en/products/firefox/the-new-firefox-by-the-numbers/
>>>> (article from 2017),
>>>>
>>>>      > 700 authors contributed code to Firefox over ~1 year
>>>>
>>>>      80 of them were volunteers, "contributors from all over the world".
>>>>
>>>> and by those 700 authors:
>>>>
>>>>      75,342 files changed
>>>>      4,888,199 lines were added
>>>>      6,886,199 lines were changed
>>>
>>> Counting just "authors" and "contributors" doesn't tell enough, but at
>>> least show the comparable numbers for Emacs, okay?
>>
>> I figured you have said numbers at hand, more or less. But they must be
>> lower.
> 
> 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.

>> If you like I can try producing them, but what point would you be trying
>> to make?
> 
> My point is that Emacs maintenance is a much more complex and
> difficult job than the job of those projects.
> 
>> The point I was trying to make that a big and complex project with many
>> contributors (bigger than ours, more complex than ours, with more
>> developers than here) can be well-served by a workflow that is rather
>> different from ours.
> 
> This remains to be shown, because the raw unanalyzed numbers you've
> presented don't provide sufficient evidence.

I'm not sure what other numbers I could provide, but if you ask 
specifically, I could try.

BTW, another project using gitlab I was thinking of is Mesa. Perhaps 
reading their moving announcement (from 5 years ago) would be of 
interest to some: 
https://lists.freedesktop.org/archives/mesa-dev/2018-May/195634.html 
There is a subsequent discussion thread as well.

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