bug#81223: [PATCH] Fix file-missing error during async native compilation

On 2026-08-10 11:52, Eli Zaretskii wrote:
>> Date: Mon, 10 Aug 2026 10:44:57 -0400
>> Cc: [email protected], [email protected], [email protected],
>>   [email protected]
>> From: James Cherti <[email protected]>
>>
>> Hello Eli and Sean,
>>
>> This patch is ready on my end, so feel free to merge it.
> 
> As you wish.

@Eli: Thank you for your understanding.

@Eli, Sean, and Philip: I took note of all your
recommendations, and I'll do my best to follow them for my
next patches. I decided to share this criticism of the
current procedures because highlighting where the review
process in the hope that it can help improve the contributor
experience.

> 
>> My commit message is not that long, and the code already includes
>> explanatory comments. I have also added the bug number in the latest
>> patch version.
> 
> I explained at length why there are still a few minor issues with your
> latest patch, and why we are asking you and others to make such
> changes.
> 
>> What I personally dislike is that the standards Sean asked
>> me to follow are not applied equally to everyone and seem
>> based on personal preference. (For example, there are many
>> long git commit messages and several commits that do not
>> adhere to the CONTRIBUTE file.)
> 
> The standards _are_ applied equally, when we have the chance to apply
> them.  Please don't forget that many people have write access to the
> repository, in which case we see the log messages after they are
> already pushed.  Your conclusion is based on what's in the repository,
> not on what we say as part of patch review.
> 
>> Manually enforcing a two-space rule or commit message length
>> limits is tedious and consumes valuable review time for Sean
>> and other maintainers. If these specific conventions are
>> required, they should be handled automatically by a linter
>> or formatter rather than human reviewers.
> 
> You can set up Emacs to do this for you, but we don't request that
> everyone uses Emacs, nor that they set it up that way, because most of
> their work could be in cultures other than US English.
> 
>> The way these small details are enforced right now is
>> unfortunately inefficient and can cause friction.
> 
> Frankly, I'm surprised that such minor requests are met with such a
> strong opposition, I don't think I've heard such objections from
> anyone else in all the years I'm involved in Emacs development.
> 
>> I recommend enforcing these minor formatting details through
>> a pre-commit hook and a server-side check.
> 
> Feel free to work on such a hook (TIA), but please keep in mind that
> it has to be 110% free of false positives, otherwise people will
> disable such a hook.  Otherwise, I'm not opposed to have such hooks,
> but they cannot catch and flag all the potential minor issues we try
> to observe in commit log messages, comments, and documentation.  For
> example, we try to avoid passive tense in our documentation, something
> that is not easy to automate.  And there are other similar aspects.

--
James Cherti
GitHub: https://github.com/jamescherti
Website: https://www.jamescherti.com/