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

[gang.yan@linux.dev]

Hi all,

Apologies for the extra email, and please don't take this as any criticism of the current workflow.

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.

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.

The Benefits

  I believe both sides will benefit clearly if the sashiko process is mitigated:

  1. For reviewers/maintainers: Their main list inbox will only contain two types of patches—brand new
     submissions (v1) and "mature" patches that have already passed the bot's checks. This drastically
     reduces noise and allows them to focus their limited reviewing bandwidth on patches that are truly
     ready for human scrutiny.
  2. For contributors: They can iterate as fast and as often as they want in the sub‑list without feeling
     guilty about flooding the main list. They get a "safe sandbox" to polish the series until it meets
     the bot's criteria. When they finally post to the main list, the patch is already in a much better
     state, which should also speed up the human review process.

I want to stress that this is not a complaint or a demand. I fully respect the work that has gone into
Sashiko and the current process.

Looking forward to hearing everyone's thoughts.

Thanks
Gang