Re: Larger GC thresholds for non-interactive Emacs

[Ihor Radchenko <yantar92@gmail.com>]

Eli Zaretskii <eliz@gnu.org> writes:

>> Then it raises a bigger question. Do we have anything better than email
>> archives to archive emacs-devel?
>
> I don't know of any.

What about Mailman 3 frontends like Hyperkitty?
https://wiki.archlinux.org/title/Hyperkitty#Xapian_search_backend

>> Note that I can also ask "what if we change debbugs?". Would it mean
>> that we should not link to bug#?
>
> The bug number gives you a quick way of reaching the bug discussion in
> the email archives of bug-gnu-emacs, and in debbugs itself.  These
> will remain available even if we switch away from debbugs as our issue
> tracker.  So the bug number is definitely a good thing to have in the
> logs.

Will the commit hash not be available e.g. on savannah? Do you intend to
remove the git history alltogether during the switch?

>> > 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.
>
> That doesn't work well IME.  Would you mind walking me though using
> that when trying to answer the above question about sbrk?

1. I listed all the commits that mentioned sbrk in the messages using
   git log, displaying the statistics. (actually, I used Magit)
2. I noticed that some of the commits changed large number of lines and
   removed sbrk-related staff. In particular, d12e5d003d Add portable
   dumper
3. I searched https://yhetil.org/emacs-devel/?q=linux+sbrk and noticed
   two candidate threads: Re: When should ralloc.c be used?; and Re:
   Dumper issue, revisited; invalid realloc/free;
4. Looking through the threads; it appears that the pdumper thread had a
   lot of occurrences of sbrk word:
   https://yhetil.org/emacs-devel/?q=%22sbrk%22
5. I skimmed through the thread and possibly found relevant message
   root:
   https://yhetil.org/emacs-devel/20140625212421.GD179@brightrain.aerifal.cx/

It would have been even easier if I had an idea what sbrk does and where
its Linux support is supposed to be in the code.

>> > 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.
>
> Two spaces between sentences is simple enough that we have several
> eyes looking for that and fixing problems post-mortem.  And yet we
> still have quite a few of them, just try searching in the Emacs tree.
> Conventions that are harder to spot are followed even less.
>
> As a matter of fact, I have hard time making sure each commit that has
> a bug number mentions that number in the commit log message.

On Org side, I do not find tracking such things too difficult. Probably
due to lesser volume of commits.

Note that things like double space, or even bug number checks could be
automated. For example, one can write a make target that checks recent
commit messages to follow specific rules.

Best,
Ihor