Patch pre-submission to Sashiko

Patch pre-submission to Sashiko

[Jiri Kosina]

[ in the spirit of the concluding discussion at this year's maintainers 
  summit,  I'm using this list outside of actual maintainer summit 
  planning :) ]

I have just received a v1 to v11 patchset submission within roughly one 
day timeframe.

Neither myself nor anyone else did comment with any review feedback, 
except for Sashiko. Which I believe is what triggered all the immediate 
resubmissions.

I don't think this is sustanable.

The idea of throttling Sashiko's responses was gently nibbled at the 
summit, and might be one of the options how to deal with this.

Another option I'd like to propose would be to introduce a way for 
submitters to run patches through back-and-forth with Sashiko even before 
properly submitting the Sashiko-polished v1 to maintainers and 
mailinglists.

Would that be possible and reasonable?

Thanks,

-- 
Jiri Kosina
SUSE Labs

Re: Patch pre-submission to Sashiko

[Theodore Tso]

On Sat, Oct 17, 2026 at 07:28:48PM -0500, Jiri Kosina wrote:
> I have just received a v1 to v11 patchset submission within roughly one 
> day timeframe.
> 
> Neither myself nor anyone else did comment with any review feedback, 
> except for Sashiko. Which I believe is what triggered all the immediate 
> resubmissions.

What some subsystem maintainers have requested is delay sashiko
reviews from being sent out by some fixed time, such as 24 hours.

One approach which might want to explore is an exponential backoff.

> Another option I'd like to propose would be to introduce a way for 
> submitters to run patches through back-and-forth with Sashiko even before 
> properly submitting the Sashiko-polished v1 to maintainers and 
> mailinglists.

It's not that hard for people to set up a local Sashiko. and then use
either an local LLM, or their own cloud-hosted AI tokens.  Perhaps
that's something we can encourage.

						- Ted

Re: Patch pre-submission to Sashiko

[Alexei Starovoitov]

On Sat Oct 17, 2026 at 5:28 PM UTC, Jiri Kosina wrote:
>
> [ in the spirit of the concluding discussion at this year's maintainers 
>   summit,  I'm using this list outside of actual maintainer summit 
>   planning :) ]
>
> I have just received a v1 to v11 patchset submission within roughly one 
> day timeframe.
>
> Neither myself nor anyone else did comment with any review feedback, 
> except for Sashiko. Which I believe is what triggered all the immediate 
> resubmissions.
>
> I don't think this is sustanable.

I think it's just fine. I encourage developers to keep the spam going.

You can simulate github style squah of v1->v2->v3 in your inbox.
Ask your agent to monitor inbox, archive vN when vN+1 arrives
and summarize v1->vN discussion. Then you'll always have the latest
patch set to look at and a summary of what happened when you were away.
Then sit on it for a day or a week to see whether respin
cycle has ended (and bots stopped talking to each other) and then
do a human part of maintainership.

Re: Patch pre-submission to Sashiko

[Linus Torvalds]

On Sat, 17 Oct 2026 at 07:39, Jiri Kosina <jikos@kernel.org> wrote:
>
> Another option I'd like to propose would be to introduce a way for
> submitters to run patches through back-and-forth with Sashiko even before
> properly submitting the Sashiko-polished v1 to maintainers and
> mailinglists.

I think maybe we should make it really easy for people to run their
some kind of sashiko setup on their own, rather than rely on sashiko
itself. After all, these are all people who use an LLM to begin with.

And assuming they sre starting out, they are probably are *not*
building their own local LLM for this either, so presumably /
hopefully they have a fairly capable LLM setup, and the problem is
primarily lack of kernel knowledge (and possibly LLM background too -
that side was certainly a learnign experience for me).

So maybe at least one piece of the puzzle is us pointing to existing
sashiko (or sashiko-like) rules so that people who use LLM's get the
"basic rules" almost by default, rather than burdening sashiko more.

.. and I do still think that we should have some kind of "sashiko
doesn't answer for 18 hours" kind of limiter. Possibly with some
back-off per submitter (and by patch series size) so that repeated
submissions get spread out even more.

                 Linus

Re: Patch pre-submission to Sashiko

[Arnaldo Melo]

On October 17, 2026 3:20:47 PM GMT-03:00, Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:
>On Sat Oct 17, 2026 at 5:28 PM UTC, Jiri Kosina wrote:
>>
>> [ in the spirit of the concluding discussion at this year's maintainers 
>>   summit,  I'm using this list outside of actual maintainer summit 
>>   planning :) ]
>>
>> I have just received a v1 to v11 patchset submission within roughly one 
>> day timeframe.
>>
>> Neither myself nor anyone else did comment with any review feedback, 
>> except for Sashiko. Which I believe is what triggered all the immediate 
>> resubmissions.
>>
>> I don't think this is sustanable.
>
>I think it's just fine. I encourage developers to keep the spam going.

Yay, agreed, it's not like before AI people were reading all of lkml (or other voluminous lists) traffic, just ignore what clearly is a conversation that now happens way faster than in the past until you see it calmed down 

The problem was not getting feedback at all, now people complain that feedback is being provided timely and then that people are responding to feedback in a timely fashion?

>You can simulate github style squah of v1->v2->v3 in your inbox.
>Ask your agent to monitor inbox, archive vN when vN+1 arrives
>and summarize v1->vN discussion. Then you'll always have the latest
>patch set to look at and a summary of what happened when you were away.
>Then sit on it for a day or a week to see whether respin
>cycle has ended (and bots stopped talking to each other) and then
>do a human part of maintainership.

+5, +1 is not enough 8-)

Fight fire with fire,  more is good, if it's too much look just at the latest patch series version when you think it slowed down. Or, if not allergic to AI, use it to summarize the previous discussion, human or trained on human data one.

When not understanding about some specific part of the latest version maybe looking at the "churn" will provide all the details you need.

- Arnaldo

Re: Patch pre-submission to Sashiko

[Andrew Lunn]

On Sat, Oct 17, 2026 at 07:28:48PM +0200, Jiri Kosina wrote:
> 
> [ in the spirit of the concluding discussion at this year's maintainers 
>   summit,  I'm using this list outside of actual maintainer summit 
>   planning :) ]
> 
> I have just received a v1 to v11 patchset submission within roughly one 
> day timeframe.

If they are iterating that fast, they either have automated tests, or
the code is untested. I would ask them to includes the tests in the
patchset, to become part of tools/testing/selftests.

	  Andrew

Re: Patch pre-submission to Sashiko

[Roman Gushchin]

Linus Torvalds <torvalds@linux-foundation.org> writes:

> On Sat, 17 Oct 2026 at 07:39, Jiri Kosina <jikos@kernel.org> wrote:
>>
>> Another option I'd like to propose would be to introduce a way for
>> submitters to run patches through back-and-forth with Sashiko even before
>> properly submitting the Sashiko-polished v1 to maintainers and
>> mailinglists.
>
> I think maybe we should make it really easy for people to run their
> some kind of sashiko setup on their own, rather than rely on sashiko
> itself. After all, these are all people who use an LLM to begin with.

It is really easy now:
$ cargo install sashiko
$ sashiko init
set the LLM key
$ cd linux && sashiko review HEAD^5..HEAD

> And assuming they sre starting out, they are probably are *not*
> building their own local LLM for this either, so presumably /
> hopefully they have a fairly capable LLM setup, and the problem is
> primarily lack of kernel knowledge (and possibly LLM background too -
> that side was certainly a learnign experience for me).
>
> So maybe at least one piece of the puzzle is us pointing to existing
> sashiko (or sashiko-like) rules so that people who use LLM's get the
> "basic rules" almost by default, rather than burdening sashiko more.

If we're adding AGENTS.md and/or skills into the kernel tree,
we can add an instruction on how to install and run local sashiko
and instruct agents to do it as the part of the process.
I actually use this for developing sashiko itself, works well.

Also I'm going to add a simple way for maintainers to add subjective
instructions (e.g. "don't send me typo fixes" or "X is frozen, don't add
new features", or "if you touch Y, run Z tests and include results"),
so hopefully it can stop some number of really bad patches before
the mailing list.

> .. and I do still think that we should have some kind of "sashiko
> doesn't answer for 18 hours" kind of limiter. Possibly with some
> back-off per submitter (and by patch series size) so that repeated
> submissions get spread out even more.

It sounds like maintainers have drastically different preferences here,
so I guess a per-mailing list configuration is the only reasonable
setup? I'm trying to be on a conservative side, so e.g. if there is no
consensus between maintainers, I do not enable emails.

Jiri, is it about some specific mailing list? We can enable e.g. 24h
embargo there.

Thanks