Re: [RFC] Mitigating Sashiko-driven iteration noise on the main MPTCP list

[Matthieu Baerts <matttbe@kernel.org>]

Hi Gang,

On 03/09/2026 08:12, gang.yan@linux.dev wrote:
> Hi all,
> 
> Apologies for the extra email, and please don't take this as any criticism of the current workflow.

Thank you for your email, it's good to discuss that.

> I'm writing this email to see if anyone else in the community shares some confusion I have
> regarding the use of Sashiko—specifically, the multiple rounds of iteration and the large
> volume of emails generated on the main list.
> 
> Let me explain the problem more clearly.
> 
> The Problem
> 
>   Since Sashiko was introduced, it has greatly accelerated patch iteration for contributors.
>   However, from a human reviewer's perspective, the main mailing list (mptcp@lists.linux.dev)
>   now carries a significantly increased volume of emails.
> 
>   Specifically, Sashiko's comments are almost exclusively directed at the original contributor,
>   who then submits a new version of the patch addressing those comments. But this process often
>   repeats for several rounds: each new version triggers additional Sashiko feedback, leading to
>   multiple intermediate patch revisions being posted to the main list. These intermediate versions
>   are only relevant to the contributor and the bot—they do not require immediate human attention,
>   yet they clutter the inboxes.
> 
>   In other words, the main list is currently used as a live iteration sandbox between Sashiko
>   and the contributor, while human reviewers are forced to watch every step of this back‑and‑forth.
>   That seems not necessary.

I agree with you here, having to face many iterations is not good for
the reviewers, and not for the devs either.

> My suggestions
> 
>   To decouple the machine‑driven iteration loop from human‑driven review, I would like to propose a
>   split workflow:
> 
>   1. Initial submission (v1): The contributor sends the first version of the patch series to the main
>      list (mptcp@lists.linux.dev). Maintainers can quickly glance at it to filter out obviously invalid
>      or low‑quality patches early.
>   2. Bot‑driven iteration (v2, v3, …): For subsequent versions that only address Sashiko's feedback,
>      the contributor posts those revisions to a separate, dedicated list (e.g., mptcp-sashiko@lists.linux.dev).
>      Sashiko watches that list and provides its feedback there. The contributor can iterate as many
>      times as needed without bothering the main list audience.
>   3. Final polished version: Once Sashiko reports no meaningful comments (or only false‑positive warnings
>      that the contributor has already handled), the contributor resends the final, cleaned‑up patch to
>      the main list for human review.
But I cannot support your suggestion :)

Sashiko's usage has a cost: it is useful to have it to flag some
potential issues, so we want to continue having it for "legit" patches.
If its usage is "abused", then we might lose it for all patches.

At the last netdev, devs got told to run pre-checks locally, including
selftests but also AI reviews (when it is possible). Many companies are
already using LLMs, then their devs should also have their patches
tested by a local Sashiko. Sashiko can be easily executed locally, with
different models. The project's README explains how to install and use
it. In short, it is supposed to be easy: configure the model to use, run
"sashiko init", then "sashiko review". That's it. Or course, we cannot
force people to use it locally. Some refs:

 -
https://netdevconf.info/0x1A/docs/netdev-0x1a-paper49-talk-slides/Device%20driver%20workshop%20(2).pdf
 - https://github.com/linux-netdev/nipa/wiki/Running-Netdev-CI-tests-locally

Ideally, authors are expected to reply to Sashiko's emails and reviewers
can help checking if Sashiko is hallucinating (which still happen
frequently...) or is asking to fix issues that cannot happen in real
deployments. But the thing is that Sashiko can review and generate a lot
of text that humans -- especially busy reviewers -- might take time to
process. So the idea here is not to rush things, and ask questions when
something is unclear or look suspicious / wrong.

In conclusion, I don't think we want a "hidden" ML, but we do want to
reduce the traffic on the ML, and the recommended solution is to push
people validating their patches with the same tool (or closed to, if
possible) before any submissions. WDYT?

Cheers,
Matt
-- 
Sponsored by the NGI0 Core fund.