Re: [PATCH 0/4] Update maintainer-pgp-guide.rst Chinese translation

[Weijie Yuan <wy@wyuan.org>]

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!