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: Mon, 27 Jun 2022 17:32:05 +0800
> 
> 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

Not sure what that means in practice.  Do you mean I should install
that locally?  Or what else?

You asked, above, do we have a better way of archiving a mailing
list, and the solution you propose seems to be yet another way of
keeping email archives?  I must be missing something.

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

No, but I don't want to look in more than one repository, either.

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

How did you decide that these threads are relevant?

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

How much time did this take you?

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

sbrk is a system call, so I guess by "its Linux support" you mean
where we used to use it Emacs?  The answer to that is not always easy
to find in practice, unless you happen to know.

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

What do you mean by "tracking"?  By "making sure" I meant the job of
having people who have write access mention the bug number.  Detecting
they missed after the commit is pushed is too late.

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

Commit log messages in Git are immutable, so looking up such problems
post-factum is not really useful.  But that is a tangent; the main
point here is that we have quite a few good practices and conventions
in place, but have problems living up to them.  So any procedure that
relies too heavily on these conventions and practices will not be too
successful, unless what it relies on is completely automated.