Re: Choice of bug tracker

[Eli Zaretskii]

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

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

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.

I hope something like this would be possible.

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

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

There are known issues with moving more stuff to ELPA, and they have
been discussed.  IME, trying to solve too many non-trivial problems
together makes the problem much harder, sometimes insoluble.

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

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

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

We are talking here about different expertise domains, not about
software complexity.  What browser needs to have experts in PL design
and implementation, in byte-compilation, in syntax analysis, in dozens
of text encodings and in Unicode standards and algorithms in general,
in half a dozen GUI toolkits and window-system events on several
platforms, in email, file I/O, sub-processes, search and replace
algorithms, in support of dozens of different programming and markup
languages?  How many of them support both GUI and TTY displays with
basically the same code?  Emacs has all of those and more, and the
day-to-day routine maintenance requires us to apply knowledge in most
of these domains.

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

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