What's cooking in zh_CN (Jul 2026, #02)

What's cooking in zh_CN (Jul 2026, #02)

[Weijie Yuan]

Here are the topics that have been cooking in Alex's tree.

Copies of the source code to Chinese documentation development tree live
in here:

    git://git.kernel.org/pub/scm/linux/kernel/git/alexs/linux.git
    https://git.kernel.org/pub/scm/linux/kernel/git/alexs/linux.git
    https://kernel.googlesource.com/pub/scm/linux/kernel/git/alexs/linux.git

Mirrors:

    https://mirrors.hust.edu.cn/git/kernel-doc-zh.git
    https://mirror.nju.edu.cn/git/kernel-doc-zh.git (experimental)

Please report any mirror instability to linux-doc@vger.kernel.org

-----------------------------------------------------------------------

NOTICE

The first "What's cooking" missed Haoyang Liu, and it so happens that
there are several topics graduating today, so the frequency of status
updates this time is relatively high.

The first time I cc'ed all relevant personnel. Is everyone happy to keep
it this way, or should I only send it to the list? I´m concerned that
unrelated discussions may create unnecessary noise in their inbox.

This report is experimental. Please feel free to offer your suggestions.

-----------------------------------------------------------------------

[Graduated to 'docs-next']

* Ben Guo (2026-07-14) 4 commits
  [PATCH v3 0/4] docs/zh_CN: update rust documentation translations
  [PATCH v3 1/4] docs/zh_CN: Update rust/quick-start.rst translation
  [PATCH v3 2/4] docs/zh_CN: Update rust/general-information.rst translation
  [PATCH v3 3/4] docs/zh_CN: Update rust/arch-support.rst translation
  [PATCH v3 4/4] docs/zh_CN: Update rust/testing.rst translation

  Merged into docs-next.

  source: https://lore.kernel.org/linux-doc/cover.1784000217.git.ben.guo@openatom.club/


* chengyaqiang (2026-05-22) 1 commit
  [PATCH] docs/zh_CN: fix KASAN SW_TAGS mode description

  Merged into docs-next.

  source: https://lore.kernel.org/linux-doc/20260522075735.2022734-1-chengyaqiang@chengyaqiang.com/

-----------------------------------------------------------------------

[Cooking]

* Doehyun Baek (2026-07-08) 7 commits
  [PATCH v6 0/7] docs/zh_CN: update DAMON translations
  [PATCH v6 1/7] docs/zh_CN: update DAMON design translation
  [PATCH v6 2/7] docs/zh_CN: add DAMON_STAT usage translation
  [PATCH v6 3/7] docs/zh_CN: update DAMON index translation
  [PATCH v6 4/7] docs/zh_CN: update DAMON start translation
  [PATCH v6 5/7] docs/zh_CN: update DAMON usage translation
  [PATCH v6 6/7] docs/zh_CN: update DAMON reclaim translation
  [PATCH v6 7/7] docs/zh_CN: update DAMON LRU sort translation

  Needs review.

  source: https://lore.kernel.org/linux-doc/20260708073246.1652828-1-doehyunbaek@gmail.com/

* Jiandong Qiu (2026-07-06) 2 commits
  [PATCH v3 0/2] docs/zh_CN: update translation of doc-guide/sphinx.rst
  [PATCH v3 1/2] docs/zh_CN: add process/changes.rst translation
  [PATCH v3 2/2] docs/zh_CN: update sphinx.rst translation

  Needs review.

  cf. https://lore.kernel.org/linux-doc/ak1SG5mw7y2UZrvR@wyuan.org/
  source: https://lore.kernel.org/linux-doc/20260706151358.2103703-1-qiujiandong1998@gmail.com/


* Yan Zhu (2026-06-12) 10 commits
  [not found] <cover.1781105672.git.zhuyan2015@qq.com>
  [PATCH 01/10] docs/zh_CN: add LSM/index Chinese translation
  [PATCH 02/10] docs/zh_CN: add LSM/apparmor Chinese translation
  [PATCH 03/10] docs/zh_CN: add LSM/LoadPin Chinese translation
  [PATCH 04/10] docs/zh_CN: add LSM/SELinux Chinese translation
  [PATCH 05/10] docs/zh_CN: add LSM/Smack Chinese translation
  [PATCH 06/10] docs/zh_CN: add LSM/tomoyo Chinese translation
  [PATCH 07/10] docs/zh_CN: add LSM/Yama Chinese translation
  [PATCH 08/10] docs/zh_CN: add LSM/SafeSetID Chinese translation
  [PATCH 09/10] docs/zh_CN: add LSM/ipe Chinese translation
  [PATCH 10/10] docs/zh_CN: add LSM/landlock Chinese translation

  Needs review.

  source: https://lore.kernel.org/linux-doc/tencent_7080BF6BB8F05936649DDC091FFD8C45210A@qq.com/
  Note: cover letter missing on lore archive.

-----------------------------------------------------------------------

[Stalled]

* Haoyang Liu (2026-03-05) 1 commit
  [PATCH] docs/zh_CN: fix an inconsistent statement in dev-tools/testing-overview

  Expecting a reroll.

  cf. https://lore.kernel.org/linux-doc/29bd0dbc-c6f9-43ce-b95f-4e787e3fe9c3@gmail.com/
  source: https://lore.kernel.org/linux-doc/20260305192048.16405-1-tttturtleruss@gmail.com/

Re: What's cooking in zh_CN (Jul 2026, #02)

[Weijie Yuan]

On Tue, Jul 14, 2026 at 10:42:34PM +0800, Weijie Yuan wrote:
> Here are the topics that have been cooking in Alex's tree.

This statement is incorrect. I will correct it next time.

Sorry for the noise.

> Copies of the source code to Chinese documentation development tree live
> in here:
> 
>     git://git.kernel.org/pub/scm/linux/kernel/git/alexs/linux.git
>     https://git.kernel.org/pub/scm/linux/kernel/git/alexs/linux.git
>     https://kernel.googlesource.com/pub/scm/linux/kernel/git/alexs/linux.git
> 
> Mirrors:
> 
>     https://mirrors.hust.edu.cn/git/kernel-doc-zh.git
>     https://mirror.nju.edu.cn/git/kernel-doc-zh.git (experimental)

Re: What's cooking in zh_CN (Jul 2026, #02)

[Weijie Yuan]

On Tue, Jul 14, 2026 at 07:05:28PM +0200, Doehyun Baek wrote:
> I "cooked" up a small website this evening that attempts to automate them:
> 
> https://doehyunbaek.github.io/cook-linux-zhcn/
> 
> Every hour, a GitHub Actions workflow scans recent `docs/zh_CN` patches on
> the linux-doc mailing list, groups rerolls, and compares their subjects
> with Alex´s `docs-next` tree to determine whether they have been applied.
> Pending series with no update for more than 30 days are classified as
> "Cold."
> 
> This is still an experimental prototype, and its heuristics may have bugs,
> particularly when threads or patch subjects change. The source is available
> here:
> 
> https://github.com/doehyunbaek/cook-linux-zhcn
> 
> Issues, suggestions, and pull requests are welcome!

Hi Doehyun,

Wow, at first glance, it seemed quite good, as a prototype.

I feel like your UI is kind of similar to sashiko? I'm fine with it.

I guess this might be the thing that Dongliang had in mind. Let's
wait for the comments from those in the UTC+8 time zone after they
wake up ;-)

Btw, for example, my patch (Weijie Yuan · docs/zh_CN: add docs-next
checkout workaround) is actually directly discarded after we reached
a consensus during our communication (with Dongliang). But it's
obvious that we didn't say it explicitly. So your website can't
recognize it automaticly right now. Perhaps we can think about how
to deal with this situation later.

Thanks for your effort,
Weijie

-- 
seems that your email doesn't show up as expected on
lore.kernel.org til now, confused..

Re: What's cooking in zh_CN (Jul 2026, #02)

[Doehyun Baek]

> Btw, for example, my patch (Weijie Yuan · docs/zh_CN: add docs-next
checkout workaround) is actually directly discarded after we reached
a consensus during our communication (with Dongliang). But it's
obvious that we didn't say it explicitly. So your website can't
recognize it automaticly right now. Perhaps we can think about how
to deal with this situation later.

Yeah, this is a downside of an automated approach: it can miss details
that are only implicit in the discussion. I see roughly three ways to
handle such cases:

1. Allow authors to mark a patch explicitly by replying with a
recognized phrase, such as `Patch-status: withdrawn`.
2. Use natural-language reasoning, perhaps with an LLM, to infer the
outcome from the discussion. I leaned against it due to cost and
complexity.
3. Leave the patch pending and let it move to “Cold” automatically
after 30 days.

I think either the first or the third option makes sense in this situation.

Thanks,
Doehyun

Re: What's cooking in zh_CN (Jul 2026, #02)

[Weijie Yuan]

On Tue, Jul 14, 2026 at 07:56:28PM +0200, Doehyun Baek wrote:
> > Btw, for example, my patch (Weijie Yuan · docs/zh_CN: add docs-next
> > checkout workaround) is actually directly discarded after we reached
> > a consensus during our communication (with Dongliang). But it's
> > obvious that we didn't say it explicitly. So your website can't
> > recognize it automaticly right now. Perhaps we can think about how
> > to deal with this situation later.
> 
> Yeah, this is a downside of an automated approach: it can miss details
> that are only implicit in the discussion. I see roughly three ways to
> handle such cases:
> 
> 1. Allow authors to mark a patch explicitly by replying with a
> recognized phrase, such as `Patch-status: withdrawn`.
> 2. Use natural-language reasoning, perhaps with an LLM, to infer the
> outcome from the discussion. I leaned against it due to cost and
> complexity.
> 3. Leave the patch pending and let it move to "Cold" automatically
> after 30 days.

Junio originally uses "Stalled", but I don't think there's a difference
though :-)

> I think either the first or the third option makes sense in this situation.

Agreed.

Re: What's cooking in zh_CN (Jul 2026, #02)

[Dongliang Mu]

On 7/15/26 1:05 AM, Doehyun Baek wrote:
> Hi Weijie,
>
> Thanks for putting together the “What’s cooking” reports!
> I "cooked" up a small website this evening that attempts to automate them:
>
> https://doehyunbaek.github.io/cook-linux-zhcn/
> <https://doehyunbaek.github.io/cook-linux-zhcn/>


This is what I want. From this webpage, I can quickly locate patches 
which needs review and start working.


>
> Every hour, a GitHub Actions workflow scans recent `docs/zh_CN` 
> patches on the linux-doc mailing list, groups rerolls, and compares 
> their subjects with Alex’s `docs-next` tree to determine whether they 
> have been applied. Pending series with no update for more than 30 days 
> are classified as “Cold.”
>
> This is still an experimental prototype, and its heuristics may have 
> bugs, particularly when threads or patch subjects change. The source 
> is available here:
>
> https://github.com/doehyunbaek/cook-linux-zhcn
> <https://github.com/doehyunbaek/cook-linux-zhcn>


Let me take a look and think what I can help contribute.


>
> Issues, suggestions, and pull requests are welcome!
>
> Thanks,
> Doehyun
>
> On Tue, Jul 14, 2026 at 5:04 PM Weijie Yuan <wy@wyuan.org> wrote:
>
>     On Tue, Jul 14, 2026 at 10:42:34PM +0800, Weijie Yuan wrote:
>     > Here are the topics that have been cooking in Alex's tree.
>
>     This statement is incorrect. I will correct it next time.
>
>     Sorry for the noise.
>
>     > Copies of the source code to Chinese documentation development
>     tree live
>     > in here:
>     >
>     >   
>      git://git.kernel.org/pub/scm/linux/kernel/git/alexs/linux.git
>     <https://mail.hust.edu.cn:8443/linkserver?dest=http%3A%2F%2Fgit.kernel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Falexs%2Flinux.git&tid=_____wAnVXVDblZqsIeJAA--.51119S3&rcpt=dzm91@hust.edu.cn&ifnotice=1&rindex=0>
>     > https://git.kernel.org/pub/scm/linux/kernel/git/alexs/linux.git
>     >
>     https://kernel.googlesource.com/pub/scm/linux/kernel/git/alexs/linux.git
>     >
>     > Mirrors:
>     >
>     > https://mirrors.hust.edu.cn/git/kernel-doc-zh.git
>     > https://mirror.nju.edu.cn/git/kernel-doc-zh.git (experimental)
>
>
>
> -- 
> Doehyun Baek

Re: What's cooking in zh_CN (Jul 2026, #02)

[Dongliang Mu]

On 7/15/26 1:42 AM, Weijie Yuan wrote:
> On Tue, Jul 14, 2026 at 07:05:28PM +0200, Doehyun Baek wrote:
>> I "cooked" up a small website this evening that attempts to automate them:
>>
>> https://doehyunbaek.github.io/cook-linux-zhcn/
>>
>> Every hour, a GitHub Actions workflow scans recent `docs/zh_CN` patches on
>> the linux-doc mailing list, groups rerolls, and compares their subjects
>> with Alex´s `docs-next` tree to determine whether they have been applied.
>> Pending series with no update for more than 30 days are classified as
>> "Cold."
>>
>> This is still an experimental prototype, and its heuristics may have bugs,
>> particularly when threads or patch subjects change. The source is available
>> here:
>>
>> https://github.com/doehyunbaek/cook-linux-zhcn
>>
>> Issues, suggestions, and pull requests are welcome!
> Hi Doehyun,
>
> Wow, at first glance, it seemed quite good, as a prototype.
>
> I feel like your UI is kind of similar to sashiko? I'm fine with it.
>
> I guess this might be the thing that Dongliang had in mind. Let's
> wait for the comments from those in the UTC+8 time zone after they
> wake up ;-)
Yes, really awesome.
>
> Btw, for example, my patch (Weijie Yuan · docs/zh_CN: add docs-next
> checkout workaround) is actually directly discarded after we reached
> a consensus during our communication (with Dongliang). But it's
> obvious that we didn't say it explicitly. So your website can't
> recognize it automaticly right now. Perhaps we can think about how
> to deal with this situation later.

We can set a terminal instruction like "Applied, thanks" to automate the 
end of patches.

Dongliang Mu

>
> Thanks for your effort,
> Weijie
>

Re: What's cooking in zh_CN (Jul 2026, #02)

[Alex Shi]

On 2026/7/15 01:05, Doehyun Baek wrote:
> Hi Weijie,
> 
> Thanks for putting together the “What’s cooking” reports!
> I "cooked" up a small website this evening that attempts to automate them:
> 
> https://doehyunbaek.github.io/cook-linux-zhcn/
> <https://doehyunbaek.github.io/cook-linux-zhcn/>

Nice work!
Maybe add a build testing result for each of patches, like 'make 
htmldocs -s', although build should pass before send out patches, but it 
often be omitted.

> Every hour, a GitHub Actions workflow scans recent `docs/zh_CN` patches 
> on the linux-doc mailing list, groups rerolls, and compares their 
> subjects with Alex’s `docs-next` tree to determine whether they have 
> been applied. Pending series with no update for more than 30 days are 
> classified as “Cold.”
> 
> This is still an experimental prototype, and its heuristics may have 
> bugs, particularly when threads or patch subjects change. The source is 
> available here:
> 
> https://github.com/doehyunbaek/cook-linux-zhcn
> <https://github.com/doehyunbaek/cook-linux-zhcn>
> Issues, suggestions, and pull requests are welcome!
> 
> Thanks,
> Doehyun

Re: What's cooking in zh_CN (Jul 2026, #02)

[Dongliang Mu]

On 7/15/26 1:56 AM, Doehyun Baek wrote:
>> Btw, for example, my patch (Weijie Yuan · docs/zh_CN: add docs-next
> checkout workaround) is actually directly discarded after we reached
> a consensus during our communication (with Dongliang). But it's
> obvious that we didn't say it explicitly. So your website can't
> recognize it automaticly right now. Perhaps we can think about how
> to deal with this situation later.
>
> Yeah, this is a downside of an automated approach: it can miss details
> that are only implicit in the discussion. I see roughly three ways to
> handle such cases:
>
> 1. Allow authors to mark a patch explicitly by replying with a
> recognized phrase, such as `Patch-status: withdrawn`.

This is better.

Or similar to syzbot, we can provide an option in the webpage to 
directly mark patchset as invalid.

> 2. Use natural-language reasoning, perhaps with an LLM, to infer the
> outcome from the discussion. I leaned against it due to cost and
> complexity.
> 3. Leave the patch pending and let it move to “Cold” automatically
> after 30 days.
Better together with 1. We may forget to reply a mark patch when busy.
>
> I think either the first or the third option makes sense in this situation.
>
> Thanks,
> Doehyun

Re: What's cooking in zh_CN (Jul 2026, #02)

[Weijie Yuan]

On Wed, Jul 15, 2026 at 09:55:35AM +0800, Dongliang Mu wrote:
> On 7/15/26 1:56 AM, Doehyun Baek wrote:
> > > Btw, for example, my patch (Weijie Yuan · docs/zh_CN: add docs-next
> > checkout workaround) is actually directly discarded after we reached
> > a consensus during our communication (with Dongliang). But it's
> > obvious that we didn't say it explicitly. So your website can't
> > recognize it automaticly right now. Perhaps we can think about how
> > to deal with this situation later.
> > 
> > Yeah, this is a downside of an automated approach: it can miss details
> > that are only implicit in the discussion. I see roughly three ways to
> > handle such cases:
> > 
> > 1. Allow authors to mark a patch explicitly by replying with a
> > recognized phrase, such as `Patch-status: withdrawn`.
> 
> This is better.
> 
> Or similar to syzbot, we can provide an option in the webpage to directly
> mark patchset as invalid.

Do we need to consider the bidirectional synchronization of the state?
If the marking is only done on the dashboard and not synchronized with
the lore list, it seems likely to cause confusion. Imagine having to
switch between two pages repeatedly to check the status of a series.


On Wed, Jul 15, 2026 at 09:46:26AM +0800, Dongliang Mu wrote:
> On 7/15/26 1:42 AM, Weijie Yuan wrote:
> > On Tue, Jul 14, 2026 at 07:05:28PM +0200, Doehyun Baek wrote:
> > > I "cooked" up a small website this evening that attempts to automate them:
> > > 
> > > https://doehyunbaek.github.io/cook-linux-zhcn/
> > > 
> > > Every hour, a GitHub Actions workflow scans recent `docs/zh_CN` patches on
> > > the linux-doc mailing list, groups rerolls, and compares their subjects
> > > with Alex´s `docs-next` tree to determine whether they have been applied.
> > > Pending series with no update for more than 30 days are classified as
> > > "Cold."
> > > 
> > > This is still an experimental prototype, and its heuristics may have bugs,
> > > particularly when threads or patch subjects change. The source is available
> > > here:
> > > 
> > > https://github.com/doehyunbaek/cook-linux-zhcn
> > > 
> > > Issues, suggestions, and pull requests are welcome!
> > Btw, for example, my patch (Weijie Yuan · docs/zh_CN: add docs-next
> > checkout workaround) is actually directly discarded after we reached
> > a consensus during our communication (with Dongliang). But it's
> > obvious that we didn't say it explicitly. So your website can't
> > recognize it automaticly right now. Perhaps we can think about how
> > to deal with this situation later.
> 
> We can set a terminal instruction like "Applied, thanks" to automate
> the end of patches.

LKML provides a bot [1] that can automatically send a email when a git pull
is done by Linus Torvalds. But it is for mainline only now. :-(

I originally planned to integrate it with our status board and avoid
having Alex manually reply "Applied" each time.

Then I realize b4 provides a feature [2] that can automatically seed
feedback to the original series when a series is merged or so. It may
save maintainer's time and trigger some automation, but I don't see our
maintainers using b4, so there's a learning cost. At the same time,
automation may bring complexity, which is a trade-off.

[1] https://korg.docs.kernel.org/prtracker.html
[2] https://b4.docs.kernel.org/en/latest/maintainer/ty.html


On Wed, Jul 15, 2026 at 09:52:20AM +0800, Alex Shi wrote:
> On 2026/7/15 01:05, Doehyun Baek wrote:
> > Hi Weijie,
> > 
> > Thanks for putting together the "What´s cooking" reports!
> > I "cooked" up a small website this evening that attempts to automate them:
> > 
> > https://doehyunbaek.github.io/cook-linux-zhcn/
> > <https://doehyunbaek.github.io/cook-linux-zhcn/>
> 
> Nice work!
> Maybe add a build testing result for each of patches, like 'make htmldocs
> -s', although build should pass before send out patches, but it often be
> omitted.

Sounds like we are going to build our own CI platform. ;-)