Re: [PATCH v2 0/5] Documentation: process: Clean up grammar, tone,

[Randy Dunlap <rdunlap@infradead.org>]

On 9/3/26 5:29 AM, Weijie Yuan wrote:
> Thanks for Cc'ing me.
> 
> On Wed, Sep 02, 2026 at 03:43:58PM +0700, Nguyen Duc Thinh wrote:
>> This patch series performs a thorough pass across several files 
>> in the Linux kernel process documentation directory. The primary focus
>> is to improve readability and maintain a professional tone throughout 
>> the guides for a global developer audience.
>>
>> Core changes include:
>> - Expanding conversational contractions (e.g., "don't" to "do not").
> 
> Is this necessary? I'm not sure.
> 
>> - Rectifying minor punctuation oversights and grammatical typos.
>> - Standardizing terminology formatting to elevate professional voice.
>>
>> Extra notes:
>> - I originally intended to send a 12-patch series to cover the whole
>>   directory, but decided to scale it back to these 5 high-quality
>>   patches to ensure thorough accuracy and a manageable review cycle.
>>   
>>   Also I want to know the current progress of the patch titled 
>>   "Capitalize Git, Quilt, and Mercurial consistently".
> 
> It has been applied:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/docs/linux.git/commit/?id=4a0be1a25d98672391e8ad2a0802f08609397274
> 
>> v2:
>>   - Resending the complete 5-patch series together as a single cohesive 
>>     thread. (Apologies, the v1 submission suffered a terminal wildcard 
>>     argument error that accidentally truncated the transmission 
>>     after 1/5).
> 
> A better practice is to name it [PATCH v1 RESEND], I guess?
> 
>> Nguyen Duc Thinh (5):
>>   Documentation: process: Clean up grammar, tone, and contractions in
>>     core files
>>   Documentation: process: Clean up grammar and tone in next guide files
>>   Documentation: process: Refine language, tone, and grammar in
>>     subsequent files
>>   Documentation: process: Refine language, tone, and grammar in
>>     subsequent files
>>   Documentation: process: Clean up grammar and tone across multiple
>>     files
> 
> Output of 'b4 shazam':
> 
> ...
> Applying: Documentation: process: Clean up grammar, tone, and contractions in core files
> Applying: Documentation: process: Clean up grammar and tone in next guide files
> Applying: Documentation: process: Refine language, tone, and grammar in subsequent files
> Applying: Documentation: process: Refine language, tone, and grammar in subsequent files
> Applying: Documentation: process: Clean up grammar and tone across multiple files
> /home/user/Projects/linux/.git/rebase-apply/patch:72: trailing whitespace.
>   License (about which more will be said below).  The author is not a
> warning: 1 line adds whitespace errors.
> /home/user/Projects/linux/.git/rebase-apply/patch:244: trailing whitespace.
> Which is nice, since there is no more insanity in the form of fake-generic
> warning: 1 line adds whitespace errors.
> /home/user/Projects/linux/.git/rebase-apply/patch:261: trailing whitespace.
>    rare cases, an AI assistant capable of finding a bug is capable of fixing it.
> /home/user/Projects/linux/.git/rebase-apply/patch:262: trailing whitespace.
>    Fixes written within the same session used to identify the bug will
> /home/user/Projects/linux/.git/rebase-apply/patch:263: trailing whitespace.
>    generally lead to better and more accurate fixes as the LLM's reasoning
> /home/user/Projects/linux/.git/rebase-apply/patch:282: trailing whitespace.
> - Within two weeks, a representative of this group will communicate the
> warning: 4 lines add whitespace errors.
> 
> Should we handle with whitespace?

No, the trailing whitespace should be fixed (i.e., deleted)
and then resend the patches.

-- 
~Randy