Re: Patch pre-submission to Sashiko

[Roman Gushchin <roman.gushchin@linux.dev>]

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