Re: Larger GC thresholds for non-interactive Emacs

[Eli Zaretskii <eliz@gnu.org>]

> From: Ihor Radchenko <yantar92@gmail.com>
> Cc: owinebar@gmail.com,  larsi@gnus.org,  monnier@iro.umontreal.ca,
>   mattiase@acm.org,  theophilusx@gmail.com,  rms@gnu.org,  acm@muc.de,
>   emacs-devel@gnu.org
> Date: Thu, 23 Jun 2022 17:03:35 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Can't the past discussions be directly updated by sending an extra email
> >> that links back to the new commit?
> >
> > You mean, rely on search engines to find an addition to a discussion
> > made many years later?  My experience with searching the archives is
> > that it many times fails when the discussion crosses the year mark.
> > For starters, display of the archives by thread doesn't work in that
> > case as expected: you are given the illusion that the thread ends.
> 
> Are you referring to lists.gnu.org thread display interface?

I mean it, but also every other mailing list software I ever used.
They all have these problems, and some more than others.

> If it is as buggy as you are describing, why don't you file a bug
> report the relevant ML and get the problem fixed?

Because I don't believe this is fixable in practice.

> There are alternatives. I personally prefer to search using local
> maildir copy via notmuch. I believe that gnus should also be able to
> search across the maildir.

I have local search set up as well, but that only works on messages I
decided to archive locally.  If you think I'm archiving every forum in
which I participate, think again ;-)

> Also, there is https://yhetil.org/ with somewhat better search and
> display interface (IMHO). See
> https://yhetil.org/emacs-devel/_/text/help/

How is it significantly better?

> > Searching the archives also has the disadvantage that in many cases
> > it's hard to know what are the keywords that would find the discussion
> > efficiently (i.e. without drowning it in thousands of irrelevant
> > messages).
> 
> When I was saying "links back to the new commit", I was referring to the
> unique commit number. Searching exact match will not give false
> positives then.

What do you do with this when we change the VCS (which happened twice
already)?

And even if you are only talking about Git SHA signatures, the "no
false positives" is not guaranteed, when messages provide only the
7-digit SHA.

And in any case, the trigger for this discussion was the situation
where you want to answer questions like "why did Emacs stop using sbrk
on GNU/Linux", in which case there's no commit ID to search for.

Moreover, I don't understand the proposal in general: are you
suggesting that every commit related to a discussion would somehow
send a message to the thread with the commit ID?  If so, how would
this work better than our (constantly failing) practice of mentioning
the bug number in the commit log messages?

These measures don't really work without a gatekeeper.  Which we don't
have, and probably never will.