Re: Larger GC thresholds for non-interactive Emacs

[Ihor Radchenko <yantar92@gmail.com>]

Eli Zaretskii <eliz@gnu.org> writes:

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

Then it raises a bigger question. Do we have anything better than email
archives to archive emacs-devel?

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

I did expect that you at least archive emacs-devel (:

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

Search is more flexible because it at least allows search by date and by
some more email fields.
Compare search section of https://yhetil.org/emacs-devel/_/text/help/
and https://lists.gnu.org/archive/cgi-bin/namazu.cgi?idxname=bug-gnu-emacs

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

Of course, things will break if we change VCS, but it should not stop us
from linking to commits - not linking at all is still worse.

Note that I can also ask "what if we change debbugs?". Would it mean
that we should not link to bug#?

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

Sure. But false positives will not be numerous. You can expect a few max
- not a big deal to check one by one.

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

I implied using git log search to identify the relevant commits.

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

I do not imply that we should do it _instead_ of mentioning bug number.
It's complementary and can be very useful (I know because I did have a
hard time finding commits that fixed particular bugs).
Also, bugs already need to be closed manually - that closing email
directive could as well include the commit hash.

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

I do not think that it is so much of an issue. Your argument would also
apply, e.g. to using double space between sentences in the commit
messages or to following log entry format. Yet people do follow these
conventions because they are documented in CONTRIBUTE file and because
non-compliant commits are being scolded. Not 100%, but frequently enough
to make the conventions useful.

Best,
Ihor