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

[johannes.goede]

Hi Ted,

On 17-Oct-26 8:02 PM, Theodore Tso wrote:
> 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.

Actually it is that hard. Even if you spend the 2000 - 3000usd
necessary to run somewhat large-ish models locally the results are
still quite slow (which by itself would be ok) and they catch
a lot less then the actual Shashiko service.

As for using "their own cloud-hosted AI tokens" I've not tried this
myself but other people with a personal "Pro" level subscription
have tried and they got blocked out of further token use for 5 hours
(throttled) after a single Shashiko review run on a 5 patch patch-
series.

So it is actually quite hard to get Shashiko to do a pre-check without
just sending of the patches to the list and the Shahiko service do
its thing.

Regards,

Hans

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

[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

[Dan Carpenter]

On Sat, Oct 17, 2026 at 03:38:36PM -0300, Arnaldo Melo wrote:
> 
> 
> 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

I read everything that's sent to drivers/staging.  I've read it in the
order that it arrives and I've done that since 2010...  But these days
people are treating the list like a pre-submit AI checker which sucks.
I feel like people are saying we should just accept that mailing lists
are just AI checker interfaces instead of being intended for humans...

I think adding a 24 hour delay to the AI review solves this.  It seems
to be working for networking.  It will likely push people to use AI
locally which is even better.

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

That has never been a problem on drivers/staging.  Greg responds
to every email and when he was on vacation then I responded to
every email.

regards,
dan carpenter

Re: Patch pre-submission to Sashiko

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1691 bytes --]

On Sat, Oct 17, 2026 at 06:20:47PM +0000, Alexei Starovoitov wrote:
> On Sat Oct 17, 2026 at 5:28 PM UTC, Jiri Kosina wrote:

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

It's not just LLM users getting caught by this, I've seen people I know
going multiple rounds in what appears to be a very human fashion trying
to shut the warnings up.  Given that some maintainers won't look at
anything until all Sashiko is happy it's a totally reasonable thing to
do but I can't imagine it's an inspiring experience.  A lot of that has
been with valid but not interesting or useful issues (the stereotypical
example is something like missing return value checks on a MMIO regmap).
Even with people who appear to be LLM users I've seen people going all
weekend with no human review only to find that the first human review is
that the approach is completely wrong and they were wasting their time
fixing the detail issues that were being flagged which I can't imagine
is especially pleasant.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

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

[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

Re: Patch pre-submission to Sashiko

[Steven Rostedt]

On Sat, 17 Oct 2026 20:10:44 +0000
Roman Gushchin <roman.gushchin@linux.dev> wrote:

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

Right. I have no issue with spamming of sashiko and back. I use
patchwork which is pretty good at only giving me the last version of a
series. And if I see that sashiko made a comment, I would have them
address it before I begin to review the series. Until sashiko is done,
I don't care if they send 11 iterations in a day. It's 11 iterations I
can ignore. In fact, that means I can start looking at it sooner.

As for Andrew's point on testing. I would hope that they would have
tested before sending v1. But sashiko is good at finding things that
tests don't catch. So if they are just fixing sashiko comments, it may
be that their tests are not catching what sashiko is finding. As
sashiko finds new issues with pretty much every new version, I can see
them having to constantly send another version with new info from
sashiko.

-- Steve

Re: Patch pre-submission to Sashiko

[Kees Cook]

On Sat, Oct 17, 2026 at 08:10:44PM +0000, Roman Gushchin wrote:
> 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

FWIW, I have been using this for a while now (and making this "local
review" mode more ergonomic). With Anthropic's recent "API credit" stuff,
this works very well with the Haiku model (Opus is outrageous over-kill
and charges you 40x more than haiku).

-- 
Kees Cook

Re: Patch pre-submission to Sashiko

[Linus Torvalds]

On Sun, 18 Oct 2026 at 08:41, Kees Cook <kees@kernel.org> wrote:
>
> On Sat, Oct 17, 2026 at 08:10:44PM +0000, Roman Gushchin wrote:
> > It is really easy now:
> > $ cargo install sashiko
> > $ sashiko init
> > set the LLM key
> > $ cd linux && sashiko review HEAD^5..HEAD
>
> FWIW, I have been using this for a while now (and making this "local
> review" mode more ergonomic). With Anthropic's recent "API credit" stuff,
> this works very well with the Haiku model (Opus is outrageous over-kill
> and charges you 40x more than haiku).

So we just need to make sure that people get this automatically, I think.

Right now you need to *know* to do this. That's a problem when at
least some of the noise comes from people who don't know the kernel,
and don't know where to look.

Hopefully the agent updates will sort some of this out and just mean
that people get a sane baseline.

               Linus

Re: Patch pre-submission to Sashiko

[Oliver Slapinski]

Hi Linus,

I'm working on an opt-in adaptive publication cooldown to address the
rapid-resubmission loop. Suppression of superseded held reviews is
implemented and tested; the adaptive policy is still in progress.

The initial scope is a capped delay based on revision activity,
preserving existing behavior when disabled. Series-size weighting and
cross-posted series are outside this first version.

I've also read your later point about discovering kernel rules and
local-review guidance automatically. That's a separate gap from the
publication limiter.

Thanks,
Oliver

On Sat, 17 Oct 2026 08:20:49 -1000, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> 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

[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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 702 bytes --]

On Sat, Oct 17, 2026 at 09:42:34PM +0200, Andrew Lunn wrote:
> On Sat, Oct 17, 2026 at 07:28:48PM +0200, Jiri Kosina wrote:

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

There's some work (init paths for drivers for example) where it's
perfectly plausible that you can reverify things fast enough to be doing
that.  It's probably a relatively long day, but it's doable.  You're
more likely to hit numbers like that over a weekend though.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: Patch pre-submission to Sashiko

[Laurent Pinchart]

On Sun, Oct 18, 2026 at 12:54:31PM +0100, Mark Brown wrote:
> On Sat, Oct 17, 2026 at 09:42:34PM +0200, Andrew Lunn wrote:
> > On Sat, Oct 17, 2026 at 07:28:48PM +0200, Jiri Kosina wrote:
> > 
> > > 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.
> 
> There's some work (init paths for drivers for example) where it's
> perfectly plausible that you can reverify things fast enough to be doing
> that.  It's probably a relatively long day, but it's doable.  You're
> more likely to hit numbers like that over a weekend though.

And let's not forget that for most patches touching drivers selftests
are not an option.

-- 
Regards,

Laurent Pinchart

Re: Patch pre-submission to Sashiko

[Krzysztof Kozlowski]

On 17/10/2026 19:28, 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 might be fine to drop usual expectation of one patchset per
24h as long as maintainers can completely ignore patchsets with Sashiko
replies.

If people want to keep bouncing the ball between them and Sashiko, they
should be allowed and then we should be allowed just to silence that
email thread completely.

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

I assume you mean they will be running it through Sashiko
infrastructure, so using sponsored tokens. Otherwise that possibility is
already there - you can run Sashiko, just a matter of money.

Best regards,
Krzysztof

Re: Patch pre-submission to Sashiko

[David Woodhouse]

[-- Attachment #1: Type: text/plain, Size: 507 bytes --]

On Mon, 2026-10-19 at 08:25 +0200, Krzysztof Kozlowski wrote:
> I assume you mean they will be running it through Sashiko
> infrastructure, so using sponsored tokens. Otherwise that possibility is
> already there - you can run Sashiko, just a matter of money.

I have a patchset in flight where I *have* been running Sashiko (as
well as lots of self-tests) locally, and then got further feedback on
the list from the public Sashiko which my own run hadn't seen. Twice.

I still need to send v3...

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 6179 bytes --]

Re: Patch pre-submission to Sashiko

[Michal Simek]

On 10/19/26 09:26, David Woodhouse wrote:
> On Mon, 2026-10-19 at 08:25 +0200, Krzysztof Kozlowski wrote:
>> I assume you mean they will be running it through Sashiko
>> infrastructure, so using sponsored tokens. Otherwise that possibility is
>> already there - you can run Sashiko, just a matter of money.
> 
> I have a patchset in flight where I *have* been running Sashiko (as
> well as lots of self-tests) locally, and then got further feedback on
> the list from the public Sashiko which my own run hadn't seen. Twice.
> 
> I still need to send v3...

Isn't it better to create a new mailing list and filter all CCs/To?
People can send patches to that mailing list and get reply without CCing 
maintainers and mailing lists. They can run a lot of iterations like that.
When it is clear they can send clear v1 in a normal way.

Thanks,
Michal

-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP/Versal ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal/Versal NET SoCs
TF-A maintainer - Xilinx ZynqMP/Versal/Versal NET SoCs

Re: Patch pre-submission to Sashiko

[Julia Lawall]

On Mon, 19 Oct 2026, Michal Simek wrote:

>
>
> On 10/19/26 09:26, David Woodhouse wrote:
> > On Mon, 2026-10-19 at 08:25 +0200, Krzysztof Kozlowski wrote:
> > > I assume you mean they will be running it through Sashiko
> > > infrastructure, so using sponsored tokens. Otherwise that possibility is
> > > already there - you can run Sashiko, just a matter of money.
> >
> > I have a patchset in flight where I *have* been running Sashiko (as
> > well as lots of self-tests) locally, and then got further feedback on
> > the list from the public Sashiko which my own run hadn't seen. Twice.
> >
> > I still need to send v3...
>
> Isn't it better to create a new mailing list and filter all CCs/To?
> People can send patches to that mailing list and get reply without CCing
> maintainers and mailing lists. They can run a lot of iterations like that.
> When it is clear they can send clear v1 in a normal way.

This isn't just free tokens for anyone who wants to make a change to the
Linux kernel, not necessarily a change that will ever be sent to a
maintainer?

julia

>
> Thanks,
> Michal
>
> --
> Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
> w: www.monstr.eu p: +42-0-721842854
> Maintainer of Linux kernel - Xilinx Microblaze
> Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP/Versal ARM64 SoCs
> U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal/Versal NET SoCs
> TF-A maintainer - Xilinx ZynqMP/Versal/Versal NET SoCs
>
>
>

Re: Patch pre-submission to Sashiko

[Michal Simek]

On 10/19/26 14:02, Julia Lawall wrote:
> 
> 
> On Mon, 19 Oct 2026, Michal Simek wrote:
> 
>>
>>
>> On 10/19/26 09:26, David Woodhouse wrote:
>>> On Mon, 2026-10-19 at 08:25 +0200, Krzysztof Kozlowski wrote:
>>>> I assume you mean they will be running it through Sashiko
>>>> infrastructure, so using sponsored tokens. Otherwise that possibility is
>>>> already there - you can run Sashiko, just a matter of money.
>>>
>>> I have a patchset in flight where I *have* been running Sashiko (as
>>> well as lots of self-tests) locally, and then got further feedback on
>>> the list from the public Sashiko which my own run hadn't seen. Twice.
>>>
>>> I still need to send v3...
>>
>> Isn't it better to create a new mailing list and filter all CCs/To?
>> People can send patches to that mailing list and get reply without CCing
>> maintainers and mailing lists. They can run a lot of iterations like that.
>> When it is clear they can send clear v1 in a normal way.
> 
> This isn't just free tokens for anyone who wants to make a change to the
> Linux kernel, not necessarily a change that will ever be sent to a
> maintainer?
Isn't this something what people can do even now? They will only keep mailing 
list and maintainer in CC.

Thanks,
Michal

-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP/Versal ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal/Versal NET SoCs
TF-A maintainer - Xilinx ZynqMP/Versal/Versal NET SoCs

Re: Patch pre-submission to Sashiko

[Julia Lawall]

> On 19 Oct 2026, at 08:46, Michal Simek <monstr@monstr.eu> wrote:
> 
> 
> 
>> On 10/19/26 14:02, Julia Lawall wrote:
>>> On Mon, 19 Oct 2026, Michal Simek wrote:
>>> 
>>> 
>>> On 10/19/26 09:26, David Woodhouse wrote:
>>>> On Mon, 2026-10-19 at 08:25 +0200, Krzysztof Kozlowski wrote:
>>>>> I assume you mean they will be running it through Sashiko
>>>>> infrastructure, so using sponsored tokens. Otherwise that possibility is
>>>>> already there - you can run Sashiko, just a matter of money.
>>>> 
>>>> I have a patchset in flight where I *have* been running Sashiko (as
>>>> well as lots of self-tests) locally, and then got further feedback on
>>>> the list from the public Sashiko which my own run hadn't seen. Twice.
>>>> 
>>>> I still need to send v3...
>>> 
>>> Isn't it better to create a new mailing list and filter all CCs/To?
>>> People can send patches to that mailing list and get reply without CCing
>>> maintainers and mailing lists. They can run a lot of iterations like that.
>>> When it is clear they can send clear v1 in a normal way.
>> This isn't just free tokens for anyone who wants to make a change to the
>> Linux kernel, not necessarily a change that will ever be sent to a
>> maintainer?
> Isn't this something what people can do even now? They will only keep mailing list and maintainer in CC.

There is still the illusion that the code risks ending up in the kernel. I guess that even with the Sashiko only list the code is still public, so perhaps that is dissuasive.


> 
> Thanks,
> Michal
> 
> --
> Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
> w: www.monstr.eu p: +42-0-721842854
> Maintainer of Linux kernel - Xilinx Microblaze
> Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP/Versal ARM64 SoCs
> U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal/Versal NET SoCs
> TF-A maintainer - Xilinx ZynqMP/Versal/Versal NET SoCs
>