.../zh_CN/process/maintainer-pgp-guide.rst | 140 ++++++++++----------- 1 file changed, 67 insertions(+), 73 deletions(-)
The script says:
$ tools/docs/checktransupdate.py Documentation/translations/zh_CN/process/maintainer-pgp-guide.rst
[1787244823.341547] Documentation/translations/zh_CN/process/maintainer-pgp-guide.rst
[1787244823.630509] commit 54857c52452a ("docs: maintainer-pgp-guide.rst: add a reference for kernel.org sign")
[1787244823.680849] commit 6c5c07bc8589 ("docs: process: maintainer-pgp-guide: update kernel.org docs link")
[1787244823.730027] commit 273aa250f138 ("Documentation: Improve wording on requirements for a free Nitrokey")
[1787244823.779408] commit f44a29784f68 ("Documentation: update maintainer-pgp-guide for latest best practices")
[1787244823.779522] 4 commits needs resolving in total
So I updated this document in chronological order, created four patches
based on these four outdated commits to make it easier for you to
review. Hence, you can freely squash them when applying them.
Tested with make htmldocs, no warning or error made by these patches.
ps. Jon, I have a little confusion regarding the license identifier.
Maybe you could take a look at it. Thanks. But that's not a big deal.
[+To: Konstantin, as he is the original author, thanks.]
---
Weijie Yuan (4):
docs/zh_CN: update maintainer-pgp-guide translation
docs/zh_CN: clarify free Nitrokey requirements
docs/zh_CN: update maintainer-pgp-guide kernel.org link
docs/zh_CN: add kernel.org trust repository reference
.../zh_CN/process/maintainer-pgp-guide.rst | 140 ++++++++++-----------
1 file changed, 67 insertions(+), 73 deletions(-)
---
base-commit: ba839bfe38d0ac2d8cbdc1272e2408dc35dafa6a
change-id: 20260820-maintainer-pgp-guide-f1f96164cfaa
On 8/21/26 1:13 AM, Weijie Yuan wrote:
> The script says:
>
> $ tools/docs/checktransupdate.py Documentation/translations/zh_CN/process/maintainer-pgp-guide.rst
> [1787244823.341547] Documentation/translations/zh_CN/process/maintainer-pgp-guide.rst
> [1787244823.630509] commit 54857c52452a ("docs: maintainer-pgp-guide.rst: add a reference for kernel.org sign")
> [1787244823.680849] commit 6c5c07bc8589 ("docs: process: maintainer-pgp-guide: update kernel.org docs link")
> [1787244823.730027] commit 273aa250f138 ("Documentation: Improve wording on requirements for a free Nitrokey")
> [1787244823.779408] commit f44a29784f68 ("Documentation: update maintainer-pgp-guide for latest best practices")
> [1787244823.779522] 4 commits needs resolving in total
>
> So I updated this document in chronological order, created four patches
> based on these four outdated commits to make it easier for you to
> review. Hence, you can freely squash them when applying them.
>
> Tested with make htmldocs, no warning or error made by these patches.
Hi Weijie,
Please make sure you execute " make cleandocs & make htmldocs". Some
warnings may be ignored by further compilation.
>
> WARNING: duplicate label kernel_org_trust_repository
>
> The same label is already defined in the English document. Please
use a translation-specific label, for example:
>
> .. _zh_kernel_org_trust_repository:
> checkpatch.pl reports:
>
> WARNING: Assisted-by expects 'AGENT_NAME:MODEL_VERSION [TOOL1]
[TOOL2]' format
>
> Please replace Assisted-by: LLM with the actual agent, model
version, and tools used.
Dongliang Mu
>
> ps. Jon, I have a little confusion regarding the license identifier.
> Maybe you could take a look at it. Thanks. But that's not a big deal.
>
> [+To: Konstantin, as he is the original author, thanks.]
>
> ---
> Weijie Yuan (4):
> docs/zh_CN: update maintainer-pgp-guide translation
> docs/zh_CN: clarify free Nitrokey requirements
> docs/zh_CN: update maintainer-pgp-guide kernel.org link
> docs/zh_CN: add kernel.org trust repository reference
>
> .../zh_CN/process/maintainer-pgp-guide.rst | 140 ++++++++++-----------
> 1 file changed, 67 insertions(+), 73 deletions(-)
>
>
> ---
> base-commit: ba839bfe38d0ac2d8cbdc1272e2408dc35dafa6a
> change-id: 20260820-maintainer-pgp-guide-f1f96164cfaa
On Fri, Aug 21, 2026 at 02:54:59PM +0800, Dongliang Mu wrote:
>
> On 8/21/26 1:13 AM, Weijie Yuan wrote:
> > The script says:
> >
> > $ tools/docs/checktransupdate.py Documentation/translations/zh_CN/process/maintainer-pgp-guide.rst
> > [1787244823.341547] Documentation/translations/zh_CN/process/maintainer-pgp-guide.rst
> > [1787244823.630509] commit 54857c52452a ("docs: maintainer-pgp-guide.rst: add a reference for kernel.org sign")
> > [1787244823.680849] commit 6c5c07bc8589 ("docs: process: maintainer-pgp-guide: update kernel.org docs link")
> > [1787244823.730027] commit 273aa250f138 ("Documentation: Improve wording on requirements for a free Nitrokey")
> > [1787244823.779408] commit f44a29784f68 ("Documentation: update maintainer-pgp-guide for latest best practices")
> > [1787244823.779522] 4 commits needs resolving in total
> >
> > So I updated this document in chronological order, created four patches
> > based on these four outdated commits to make it easier for you to
> > review. Hence, you can freely squash them when applying them.
> >
> > Tested with make htmldocs, no warning or error made by these patches.
>
> Hi Weijie,
>
> Please make sure you execute " make cleandocs & make htmldocs". Some
> warnings may be ignored by further compilation.
Hi!
Thanks for emphasizing this. While I do remember I used "make cleandocs
&& make htmldocs", and checked among those long lines of red warning
output to find anything caused by my commit, I indeed didn't notice this
warning appearing at the early stage of the compilation.
It seems that I need to have my eyes checked soon. ;-)
Apologize for my recklessness.
Even so, do we have any way to distinguish these long-standing warnings
from the new warnings that appear during compilation? In fact, every
time I was worried that I might not have noticed the newly appeared
warning. Unfortunately, this time it really happened. (For example,
setting a new color? for new warnings?) Do you have a better idea or
tips for this?
Btw I've been trying to know more about Sphinx and kernel-docs, hope my
mistake won't happen again.
Thanks.
> > WARNING: duplicate label kernel_org_trust_repository
> >
> > The same label is already defined in the English document. Please use a translation-specific label, for example:
> >
> > .. _zh_kernel_org_trust_repository:
> > checkpatch.pl reports:
> >
> > WARNING: Assisted-by expects 'AGENT_NAME:MODEL_VERSION [TOOL1] [TOOL2]' format
> >
> > Please replace Assisted-by: LLM with the actual agent, model version, and tools used.
And this one has been updated from Jon's PR last night, so I ignored
this output, left just a simple LLM.
On 8/21/26 3:22 PM, Weijie Yuan wrote:
> On Fri, Aug 21, 2026 at 02:54:59PM +0800, Dongliang Mu wrote:
>> On 8/21/26 1:13 AM, Weijie Yuan wrote:
>>> The script says:
>>>
>>> $ tools/docs/checktransupdate.py Documentation/translations/zh_CN/process/maintainer-pgp-guide.rst
>>> [1787244823.341547] Documentation/translations/zh_CN/process/maintainer-pgp-guide.rst
>>> [1787244823.630509] commit 54857c52452a ("docs: maintainer-pgp-guide.rst: add a reference for kernel.org sign")
>>> [1787244823.680849] commit 6c5c07bc8589 ("docs: process: maintainer-pgp-guide: update kernel.org docs link")
>>> [1787244823.730027] commit 273aa250f138 ("Documentation: Improve wording on requirements for a free Nitrokey")
>>> [1787244823.779408] commit f44a29784f68 ("Documentation: update maintainer-pgp-guide for latest best practices")
>>> [1787244823.779522] 4 commits needs resolving in total
>>>
>>> So I updated this document in chronological order, created four patches
>>> based on these four outdated commits to make it easier for you to
>>> review. Hence, you can freely squash them when applying them.
>>>
>>> Tested with make htmldocs, no warning or error made by these patches.
>> Hi Weijie,
>>
>> Please make sure you execute " make cleandocs & make htmldocs". Some
>> warnings may be ignored by further compilation.
> Hi!
>
> Thanks for emphasizing this. While I do remember I used "make cleandocs
> && make htmldocs", and checked among those long lines of red warning
> output to find anything caused by my commit, I indeed didn't notice this
> warning appearing at the early stage of the compilation.
>
> It seems that I need to have my eyes checked soon. ;-)
>
> Apologize for my recklessness.
>
> Even so, do we have any way to distinguish these long-standing warnings
> from the new warnings that appear during compilation? In fact, every
> time I was worried that I might not have noticed the newly appeared
> warning. Unfortunately, this time it really happened. (For example,
> setting a new color? for new warnings?) Do you have a better idea or
> tips for this?
My suggestion is to keep the log in each file, and you can easily
observe the diff. Otherwise, even I can ignore some warnings.
And many contributors are coming together to fix those warnings. If they
are done, all new warnings are easily captured. Let us do more
contribution to help this.
Dongliang Mu
>
> Btw I've been trying to know more about Sphinx and kernel-docs, hope my
> mistake won't happen again.
That change can fix problem. The underlying problem is RST syntax. Maybe
you can have a look at this or query it in the LLM.
Dongliang Mu
>
> Thanks.
>
>> > WARNING: duplicate label kernel_org_trust_repository
>> >
>> > The same label is already defined in the English document. Please use a translation-specific label, for example:
>> >
>> > .. _zh_kernel_org_trust_repository:
>
>> > checkpatch.pl reports:
>> >
>> > WARNING: Assisted-by expects 'AGENT_NAME:MODEL_VERSION [TOOL1] [TOOL2]' format
>> >
>> > Please replace Assisted-by: LLM with the actual agent, model version, and tools used.
> And this one has been updated from Jon's PR last night, so I ignored
> this output, left just a simple LLM.
On Fri, Aug 21, 2026 at 07:18:56PM +0800, Dongliang Mu wrote: > > [...] > > Thanks for emphasizing this. While I do remember I used "make cleandocs > > && make htmldocs", and checked among those long lines of red warning > > output to find anything caused by my commit, I indeed didn't notice this > > warning appearing at the early stage of the compilation. > > > > It seems that I need to have my eyes checked soon. ;-) > > > > Apologize for my recklessness. > > > > Even so, do we have any way to distinguish these long-standing warnings > > from the new warnings that appear during compilation? In fact, every > > time I was worried that I might not have noticed the newly appeared > > warning. Unfortunately, this time it really happened. (For example, > > setting a new color? for new warnings?) Do you have a better idea or > > tips for this? > > My suggestion is to keep the log in each file, and you can easily observe > the diff. Otherwise, even I can ignore some warnings. Ah, makes sense! I was actually wondering earlier why we need to put this log in the directory instead of just keeping it in the CLI. (I definitely won´t admit that the log file annoyed me a few times because I accidentally included it with 'git add .' and then had to 'git commit --amend' right after) ;-) Very useful, thanks! > And many contributors are coming together to fix those warnings. If they are > done, all new warnings are easily captured. Let us do more contribution to > help this. Yeah, eliminating these warnings at their root is the straightforward solution. And that's exactly what Jon expects: Kernel Recipes 2019 - Kernel documentation: past, present, and future #Build warnings https://youtu.be/1LuAIUKqKDk?t=876&si=XgHhHtukyjyDdtzF It'd certainly be worth spending some time with folks from those subsystems to get these warnings fixed once and for all. > > Btw I've been trying to know more about Sphinx and kernel-docs, hope my > > mistake won't happen again. > > That change can fix problem. The underlying problem is RST syntax. Maybe you > can have a look at this or query it in the LLM. Absolutely. I did have relatively little experience writing rst before. But that's definitely no excuse - I'll try to pick it up quickly. Thanks!
On 8/21/26 7:56 PM, Weijie Yuan wrote: > On Fri, Aug 21, 2026 at 07:18:56PM +0800, Dongliang Mu wrote: >>> [...] >>> Thanks for emphasizing this. While I do remember I used "make cleandocs >>> && make htmldocs", and checked among those long lines of red warning >>> output to find anything caused by my commit, I indeed didn't notice this >>> warning appearing at the early stage of the compilation. >>> >>> It seems that I need to have my eyes checked soon. ;-) >>> >>> Apologize for my recklessness. >>> >>> Even so, do we have any way to distinguish these long-standing warnings >>> from the new warnings that appear during compilation? In fact, every >>> time I was worried that I might not have noticed the newly appeared >>> warning. Unfortunately, this time it really happened. (For example, >>> setting a new color? for new warnings?) Do you have a better idea or >>> tips for this? >> My suggestion is to keep the log in each file, and you can easily observe >> the diff. Otherwise, even I can ignore some warnings. > Ah, makes sense! I was actually wondering earlier why we need to put > this log in the directory instead of just keeping it in the CLI. > > (I definitely won´t admit that the log file annoyed me a few times > because I accidentally included it with 'git add .' and then had to 'git > commit --amend' right after) ;-) My experience is to not use 'git add .'. In Linux, hidden files are not listed by default. > Very useful, thanks! > >> And many contributors are coming together to fix those warnings. If they are >> done, all new warnings are easily captured. Let us do more contribution to >> help this. > Yeah, eliminating these warnings at their root is the straightforward > solution. > > And that's exactly what Jon expects: > > Kernel Recipes 2019 - Kernel documentation: past, present, and future > #Build warnings > > https://youtu.be/1LuAIUKqKDk?t=876&si=XgHhHtukyjyDdtzF > > It'd certainly be worth spending some time with folks from those > subsystems to get these warnings fixed once and for all. Yes, you are right. Eliminating these warnings need collaboration from other subsystems. > >>> Btw I've been trying to know more about Sphinx and kernel-docs, hope my >>> mistake won't happen again. >> That change can fix problem. The underlying problem is RST syntax. Maybe you >> can have a look at this or query it in the LLM. > Absolutely. I did have relatively little experience writing rst before. > But that's definitely no excuse - I'll try to pick it up quickly. LLM is really useful to capture some syntax and semantics issues. Therefore, before submitting patch, use LLM to scan problem in this issue. I am writing a draft skill for reviewing patches of kernel Chinese documentation. Dongliang Mu > > Thanks!
On Fri, Aug 21, 2026 at 08:17:06PM +0800, Dongliang Mu wrote: [...] > > (I definitely won't admit that the log file annoyed me a few times > > because I accidentally included it with 'git add .' and then had to 'git > > commit --amend' right after) ;-) > My experience is to not use 'git add .'. In Linux, hidden files are not > listed by default. Yes, I was being lazy to type the full pach/full file name, oops. While hidden files are not listed by default on Linux, thankfully the kernel source tree ignores .* via .gitignore. But 'git add .' is indeed a bad habit. Btw, git commit -v, or setting commit.verbose = true, can really save one at the last minute. (as mentioned in our how-to doc) And sadly I actually happened to use another computer to write patches last night, which I hadn't configured it. XD [...] > > > > Btw I've been trying to know more about Sphinx and kernel-docs, hope my > > > > mistake won't happen again. > > > That change can fix problem. The underlying problem is RST syntax. Maybe you > > > can have a look at this or query it in the LLM. > > Absolutely. I did have relatively little experience writing rst before. > > But that's definitely no excuse - I'll try to pick it up quickly. > LLM is really useful to capture some syntax and semantics issues. Therefore, > before submitting patch, use LLM to scan problem in this issue. Got it, thanks. > I am writing a draft skill for reviewing patches of kernel Chinese > documentation. Nice! I've been trying "b4 review tui" these days and I also made some modifications to its pre-configured prompt to fit our specific workflows: https://git.kernel.org/pub/scm/utils/b4/b4.git/tree/misc/agent-reviewer.md b4 review tui 'agents' - AI-assisted review: https://b4.docs.kernel.org/en/latest/reviewer/getting-started.html#ai-assisted-review Sometimes my agent makes false alarms, but at other times it does manage to identify the issues that we have overlooked. This is probably also one of the reasons why the community is gradually becoming more accepting of LLMs. Thanks!
On 8/21/26 8:48 PM, Weijie Yuan wrote: > On Fri, Aug 21, 2026 at 08:17:06PM +0800, Dongliang Mu wrote: > [...] >>> (I definitely won't admit that the log file annoyed me a few times >>> because I accidentally included it with 'git add .' and then had to 'git >>> commit --amend' right after) ;-) >> My experience is to not use 'git add .'. In Linux, hidden files are not >> listed by default. > Yes, I was being lazy to type the full pach/full file name, oops. > > While hidden files are not listed by default on Linux, thankfully the > kernel source tree ignores .* via .gitignore. But 'git add .' is indeed > a bad habit. > > Btw, git commit -v, or setting commit.verbose = true, can really save > one at the last minute. (as mentioned in our how-to doc) And sadly I > actually happened to use another computer to write patches last night, > which I hadn't configured it. XD Actually these labor-tensive works should be done by LLM. This is one of the right directions of LLM usage. You can write a simple skill to help you complete these works. > > [...] >>>>> Btw I've been trying to know more about Sphinx and kernel-docs, hope my >>>>> mistake won't happen again. >>>> That change can fix problem. The underlying problem is RST syntax. Maybe you >>>> can have a look at this or query it in the LLM. >>> Absolutely. I did have relatively little experience writing rst before. >>> But that's definitely no excuse - I'll try to pick it up quickly. >> LLM is really useful to capture some syntax and semantics issues. Therefore, >> before submitting patch, use LLM to scan problem in this issue. > Got it, thanks. > >> I am writing a draft skill for reviewing patches of kernel Chinese >> documentation. > Nice! I've been trying "b4 review tui" these days and I also made some > modifications to its pre-configured prompt to fit our specific > workflows: > > https://git.kernel.org/pub/scm/utils/b4/b4.git/tree/misc/agent-reviewer.md > > b4 review tui 'agents' - AI-assisted review: > > https://b4.docs.kernel.org/en/latest/reviewer/getting-started.html#ai-assisted-review > > Sometimes my agent makes false alarms, but at other times it does manage > to identify the issues that we have overlooked. This is probably also > one of the reasons why the community is gradually becoming more > accepting of LLMs. Ah, this is interesting. My skill is to use LLM to search the patch name, use b4 to apply patches and finally ask LLM to refer to how-to.rst and review the patch or patchset. And I think we could try to add our subsystem to sashiko. What we need to do is to write some subsystem-related prompts. Dongliang Mu > > Thanks!
On Fri, Aug 21, 2026 at 08:57:46PM +0800, Dongliang Mu wrote: > > On 8/21/26 8:48 PM, Weijie Yuan wrote: > > On Fri, Aug 21, 2026 at 08:17:06PM +0800, Dongliang Mu wrote: > > [...] > > > > (I definitely won't admit that the log file annoyed me a few times > > > > because I accidentally included it with 'git add .' and then had to 'git > > > > commit --amend' right after) ;-) > > > My experience is to not use 'git add .'. In Linux, hidden files are not > > > listed by default. > > Yes, I was being lazy to type the full pach/full file name, oops. > > > > While hidden files are not listed by default on Linux, thankfully the > > kernel source tree ignores .* via .gitignore. But 'git add .' is indeed > > a bad habit. > > > > Btw, git commit -v, or setting commit.verbose = true, can really save > > one at the last minute. (as mentioned in our how-to doc) And sadly I > > actually happened to use another computer to write patches last night, > > which I hadn't configured it. XD > > Actually these labor-tensive works should be done by LLM. This is one of the > right directions of LLM usage. > > You can write a simple skill to help you complete these works. That makes sense. I'll give it a try. Still, given that the kernel community tends to be a bit conservative, I've generally tried to do things myself. Of course, the most important thing is that we supervise what the LLM is doing and make sure it follows our actual intent rather than hallucinating. > > > > > > Btw I've been trying to know more about Sphinx and kernel-docs, hope my > > > > > > mistake won't happen again. > > > > > That change can fix problem. The underlying problem is RST syntax. Maybe you > > > > > can have a look at this or query it in the LLM. > > > > Absolutely. I did have relatively little experience writing rst before. > > > > But that's definitely no excuse - I'll try to pick it up quickly. > > > LLM is really useful to capture some syntax and semantics issues. Therefore, > > > before submitting patch, use LLM to scan problem in this issue. > > Got it, thanks. > > > > > I am writing a draft skill for reviewing patches of kernel Chinese > > > documentation. > > Nice! I've been trying "b4 review tui" these days and I also made some > > modifications to its pre-configured prompt to fit our specific > > workflows: > > > > https://git.kernel.org/pub/scm/utils/b4/b4.git/tree/misc/agent-reviewer.md > > > > b4 review tui 'agents' - AI-assisted review: > > > > https://b4.docs.kernel.org/en/latest/reviewer/getting-started.html#ai-assisted-review > > > > Sometimes my agent makes false alarms, but at other times it does manage > > to identify the issues that we have overlooked. This is probably also > > one of the reasons why the community is gradually becoming more > > accepting of LLMs. > > Ah, this is interesting. > > My skill is to use LLM to search the patch name, use b4 to apply patches and > finally ask LLM to refer to how-to.rst and review the patch or patchset. As Chen-Yu mentioned before, I´ve basically trained myself to find almost any email in the lore archives manually. ;-) And yes, every time before I send a patch, I have an LLM check whether it follows the instructions in the how-to.rst. > And I think we could try to add our subsystem to sashiko. What we need to do > is to write some subsystem-related prompts. I was thinking about this a few days ago. I'd actually planned to talk to the Sashiko maintainer about it first, but I haven´t gotten around to it yet. As far as I know, though, Sashiko can currently only be enabled based on mailing lists; it can't filter or match patches specifically for the Chinese translation subsystem. Overall, though, I´m in favor of enabling Sashiko for us. Having an extra pair of automated eyes certainly doesn't hurt. That said, some settings may be worth discussing - for example, whether the Sashiko bot should be allowed to send review comments directly to the original patch thread. Thanks!
On 8/21/26 9:11 PM, Weijie Yuan wrote: > On Fri, Aug 21, 2026 at 08:57:46PM +0800, Dongliang Mu wrote: >> On 8/21/26 8:48 PM, Weijie Yuan wrote: >>> On Fri, Aug 21, 2026 at 08:17:06PM +0800, Dongliang Mu wrote: >>> [...] >>>>> (I definitely won't admit that the log file annoyed me a few times >>>>> because I accidentally included it with 'git add .' and then had to 'git >>>>> commit --amend' right after) ;-) >>>> My experience is to not use 'git add .'. In Linux, hidden files are not >>>> listed by default. >>> Yes, I was being lazy to type the full pach/full file name, oops. >>> >>> While hidden files are not listed by default on Linux, thankfully the >>> kernel source tree ignores .* via .gitignore. But 'git add .' is indeed >>> a bad habit. >>> >>> Btw, git commit -v, or setting commit.verbose = true, can really save >>> one at the last minute. (as mentioned in our how-to doc) And sadly I >>> actually happened to use another computer to write patches last night, >>> which I hadn't configured it. XD >> Actually these labor-tensive works should be done by LLM. This is one of the >> right directions of LLM usage. >> >> You can write a simple skill to help you complete these works. > That makes sense. I'll give it a try. Still, given that the kernel > community tends to be a bit conservative, I've generally tried to do > things myself. Of course, the most important thing is that we supervise > what the LLM is doing and make sure it follows our actual intent rather > than hallucinating. My experience is to always double check the result of LLM. However, to be honest, translation is not a complicated task. Sometimes LLM proposes greater translation than me. And LLM is really good at capturing some common problems in the patchset. > >>>>>>> Btw I've been trying to know more about Sphinx and kernel-docs, hope my >>>>>>> mistake won't happen again. >>>>>> That change can fix problem. The underlying problem is RST syntax. Maybe you >>>>>> can have a look at this or query it in the LLM. >>>>> Absolutely. I did have relatively little experience writing rst before. >>>>> But that's definitely no excuse - I'll try to pick it up quickly. >>>> LLM is really useful to capture some syntax and semantics issues. Therefore, >>>> before submitting patch, use LLM to scan problem in this issue. >>> Got it, thanks. >>> >>>> I am writing a draft skill for reviewing patches of kernel Chinese >>>> documentation. >>> Nice! I've been trying "b4 review tui" these days and I also made some >>> modifications to its pre-configured prompt to fit our specific >>> workflows: >>> >>> https://git.kernel.org/pub/scm/utils/b4/b4.git/tree/misc/agent-reviewer.md >>> >>> b4 review tui 'agents' - AI-assisted review: >>> >>> https://b4.docs.kernel.org/en/latest/reviewer/getting-started.html#ai-assisted-review >>> >>> Sometimes my agent makes false alarms, but at other times it does manage >>> to identify the issues that we have overlooked. This is probably also >>> one of the reasons why the community is gradually becoming more >>> accepting of LLMs. >> Ah, this is interesting. >> >> My skill is to use LLM to search the patch name, use b4 to apply patches and >> finally ask LLM to refer to how-to.rst and review the patch or patchset. > As Chen-Yu mentioned before, I´ve basically trained myself to find > almost any email in the lore archives manually. ;-) > > And yes, every time before I send a patch, I have an LLM check whether > it follows the instructions in the how-to.rst. Please take a look at my review: https://lore.kernel.org/all/b45c6389-a048-4a94-8649-ab0c5a80fac2@hust.edu.cn/ The first comment is from Codex + ChatGPT. And my skill complains the following warning: https://lore.kernel.org/all/7724c093-cb99-490d-b632-1381e16962ff@hust.edu.cn/ > >> And I think we could try to add our subsystem to sashiko. What we need to do >> is to write some subsystem-related prompts. > I was thinking about this a few days ago. I'd actually planned to talk > to the Sashiko maintainer about it first, but I haven´t gotten around > to it yet. As far as I know, though, Sashiko can currently only be > enabled based on mailing lists; it can't filter or match patches > specifically for the Chinese translation subsystem. > > Overall, though, I´m in favor of enabling Sashiko for us. Having an > extra pair of automated eyes certainly doesn't hurt. That said, some > settings may be worth discussing - for example, whether the Sashiko bot > should be allowed to send review comments directly to the original patch > thread. Maybe we can do some tricks in the prompt. docs/zh_CN: is an obvious signal for us. > > Thanks!
On Fri, Aug 21, 2026 at 09:45:26PM +0800, Dongliang Mu wrote: > On 8/21/26 9:11 PM, Weijie Yuan wrote: > > On Fri, Aug 21, 2026 at 08:57:46PM +0800, Dongliang Mu wrote: > > > On 8/21/26 8:48 PM, Weijie Yuan wrote: > > > > On Fri, Aug 21, 2026 at 08:17:06PM +0800, Dongliang Mu wrote: > > > > [...] > > > > > > (I definitely won't admit that the log file annoyed me a few times > > > > > > because I accidentally included it with 'git add .' and then had to 'git > > > > > > commit --amend' right after) ;-) > > > > > My experience is to not use 'git add .'. In Linux, hidden files are not > > > > > listed by default. > > > > Yes, I was being lazy to type the full pach/full file name, oops. > > > > > > > > While hidden files are not listed by default on Linux, thankfully the > > > > kernel source tree ignores .* via .gitignore. But 'git add .' is indeed > > > > a bad habit. > > > > > > > > Btw, git commit -v, or setting commit.verbose = true, can really save > > > > one at the last minute. (as mentioned in our how-to doc) And sadly I > > > > actually happened to use another computer to write patches last night, > > > > which I hadn't configured it. XD > > > Actually these labor-tensive works should be done by LLM. This is one of the > > > right directions of LLM usage. > > > > > > You can write a simple skill to help you complete these works. > > That makes sense. I'll give it a try. Still, given that the kernel > > community tends to be a bit conservative, I've generally tried to do > > things myself. Of course, the most important thing is that we supervise > > what the LLM is doing and make sure it follows our actual intent rather > > than hallucinating. > > My experience is to always double check the result of LLM. > > However, to be honest, translation is not a complicated task. Sometimes LLM > proposes greater translation than me. Aha, yes, I said that in [PATCH 1/4] too. ;-) > And LLM is really good at capturing some common problems in the patchset. Yes, agreed. > > > > > > > > Btw I've been trying to know more about Sphinx and kernel-docs, hope my > > > > > > > > mistake won't happen again. > > > > > > > That change can fix problem. The underlying problem is RST syntax. Maybe you > > > > > > > can have a look at this or query it in the LLM. > > > > > > Absolutely. I did have relatively little experience writing rst before. > > > > > > But that's definitely no excuse - I'll try to pick it up quickly. > > > > > LLM is really useful to capture some syntax and semantics issues. Therefore, > > > > > before submitting patch, use LLM to scan problem in this issue. > > > > Got it, thanks. > > > > > > > > > I am writing a draft skill for reviewing patches of kernel Chinese > > > > > documentation. > > > > Nice! I've been trying "b4 review tui" these days and I also made some > > > > modifications to its pre-configured prompt to fit our specific > > > > workflows: > > > > > > > > https://git.kernel.org/pub/scm/utils/b4/b4.git/tree/misc/agent-reviewer.md > > > > > > > > b4 review tui 'agents' - AI-assisted review: > > > > > > > > https://b4.docs.kernel.org/en/latest/reviewer/getting-started.html#ai-assisted-review > > > > > > > > Sometimes my agent makes false alarms, but at other times it does manage > > > > to identify the issues that we have overlooked. This is probably also > > > > one of the reasons why the community is gradually becoming more > > > > accepting of LLMs. > > > Ah, this is interesting. > > > > > > My skill is to use LLM to search the patch name, use b4 to apply patches and > > > finally ask LLM to refer to how-to.rst and review the patch or patchset. > > As Chen-Yu mentioned before, I´ve basically trained myself to find > > almost any email in the lore archives manually. ;-) > > > > And yes, every time before I send a patch, I have an LLM check whether > > it follows the instructions in the how-to.rst. > > Please take a look at my review: > > https://lore.kernel.org/all/b45c6389-a048-4a94-8649-ab0c5a80fac2@hust.edu.cn/ > > The first comment is from Codex + ChatGPT. > > And my skill complains the following warning: > > https://lore.kernel.org/all/7724c093-cb99-490d-b632-1381e16962ff@hust.edu.cn/ I'm looking at right now ;-) because I'm at the "blame" line already. > > > > > And I think we could try to add our subsystem to sashiko. What we need to do > > > is to write some subsystem-related prompts. > > I was thinking about this a few days ago. I'd actually planned to talk > > to the Sashiko maintainer about it first, but I haven´t gotten around > > to it yet. As far as I know, though, Sashiko can currently only be > > enabled based on mailing lists; it can't filter or match patches > > specifically for the Chinese translation subsystem. > > > > Overall, though, I´m in favor of enabling Sashiko for us. Having an > > extra pair of automated eyes certainly doesn't hurt. That said, some > > settings may be worth discussing - for example, whether the Sashiko bot > > should be allowed to send review comments directly to the original patch > > thread. > > Maybe we can do some tricks in the prompt. docs/zh_CN: is an obvious signal > for us. Yes, I'll take a look at it later.
© 2016 - 2026 Red Hat, Inc.