Re: Larger GC thresholds for non-interactive Emacs

[Ihor Radchenko]

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.

I am trying to challenge your statement that thread display is bad in
mailing list web frontends. I fail to believe that the problem with year
crossing is impossible to solve. So, I suggested that a newer Mailman
frontend might not have the described problem. Can we use it in
lists.gnu.org instead of the older web interface?

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

My initial suggestion was bi-directional linking between the commit
messages and the relevant ML discussions. There is already a convention
to link from commit messages to debbugs, but it would be useful to have
the backlinks from debbugs/ML to the relevant commits. Via commit hash
or possibly via direct savannah link (whatever is more permanent).

I do not think that there is any way to have the commits directly in
debbugs. (Or am I wrong?)

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

ralloc.c and pdumper where the keywords used both in the commits and in
the threads. And there were significant number of matching messages in
the threads.

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

The total time I spent replying to your email was 42 minutes (recorded).
Out of those 42 minutes I subjectively spent 10-15 minutes trying to
answer "Would you mind walking me though using that when trying to
answer the above question about sbrk?". Not more than 25 minutes max.

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

You are right. I mostly had to deal with people who do not have write
access.

As for automatic checks for all the committers, what about git pre-push
hooks (https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks)?
If one can write make commit_check target, it can be configured to run
before pushing to Emacs upstream.

Best,
Ihor