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

[gang.yan@linux.dev]

September 3, 2026 at 5:52 PM, "Matthieu Baerts" <matttbe@kernel.org mailto:matttbe@kernel.org?to=%22Matthieu%20Baerts%22%20%3Cmatttbe%40kernel.org%3E > wrote:

Hi, Matt

Thanks for your reply and detailed explanation.

> 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?

I now see that my idea was probably too naive/overly simplistic :)

I have tried deploying Sashiko locally and noticed that different models can
produce quite different review outputs. For now, I am willing to defer to the
community's existing practice.

Thanks again for your time.

Cheers,
Gang

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