public inbox for rust-for-linux@vger.kernel.org
 help / color / mirror / Atom feed
* Maybe make Sashiko emails opt-in please?
@ 2026-04-23  1:10 lyude
  2026-04-23  1:48 ` Alexandre Courbot
  0 siblings, 1 reply; 6+ messages in thread
From: lyude @ 2026-04-23  1:10 UTC (permalink / raw)
  To: rust-for-linux

Hi! I was told on the github for sashiko that I should probably bring
this issue up here. (source:
https://github.com/sashiko-dev/sashiko/pull/112 )

I sent two patch series to the rust-for-linux mailing list last night,
and was a bit surprised to see that all of a sudden I am getting
Sashiko emails on my patches without having asked for them. Which
brings me to say - I really think this is a tool that needs to remain
opt-in. Or at the very least it needs an opt-out that at least silences
it trying to respond to a specific person's patches both directly and
via the mailing list.

I'm going to keep it short because I am really trying to avoid this
turning into a conversation about how I could benefit from these tools,
how useful people think they are for themselves, etc. I personally
don't find myself being more productive with these tools, primarily
because of the significant number of false-positives and the overhead
involved in filtering those by hand. I'm concerned that if these tools
are suddenly allowed to respond to people's patches publicly on the
mailing list, that it moves the responsibility for validating its
output away from the person using the tool, to the person submitting
the work - regardless of whether it's helping them fix real issues.

Keep in mind, I do want to be clear I think this is different from when
people use these tools on their own and bring that feedback up on the
mailing list. In that case you've taken the responsibility to actually
verify the validity (or at least the likely validity) of the issues the
AI pointed out. I certainly would have no issue with that and
appreciate the issue being brought up. I know a number of my coworkers
do this, and I've honestly not had any issues with it.

That's all, I'd love if this was opt-in - and not enabled for the
entire mailing list. Thank you.


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Maybe make Sashiko emails opt-in please?
  2026-04-23  1:10 Maybe make Sashiko emails opt-in please? lyude
@ 2026-04-23  1:48 ` Alexandre Courbot
  2026-04-23 20:24   ` John Hubbard
  0 siblings, 1 reply; 6+ messages in thread
From: Alexandre Courbot @ 2026-04-23  1:48 UTC (permalink / raw)
  To: lyude; +Cc: rust-for-linux

On Thu Apr 23, 2026 at 10:10 AM JST, lyude wrote:
> Hi! I was told on the github for sashiko that I should probably bring
> this issue up here. (source:
> https://github.com/sashiko-dev/sashiko/pull/112 )
>
> I sent two patch series to the rust-for-linux mailing list last night,
> and was a bit surprised to see that all of a sudden I am getting
> Sashiko emails on my patches without having asked for them. Which
> brings me to say - I really think this is a tool that needs to remain
> opt-in. Or at the very least it needs an opt-out that at least silences
> it trying to respond to a specific person's patches both directly and
> via the mailing list.
>
> I'm going to keep it short because I am really trying to avoid this
> turning into a conversation about how I could benefit from these tools,
> how useful people think they are for themselves, etc. I personally
> don't find myself being more productive with these tools, primarily
> because of the significant number of false-positives and the overhead
> involved in filtering those by hand. I'm concerned that if these tools
> are suddenly allowed to respond to people's patches publicly on the
> mailing list, that it moves the responsibility for validating its
> output away from the person using the tool, to the person submitting
> the work - regardless of whether it's helping them fix real issues.
>
> Keep in mind, I do want to be clear I think this is different from when
> people use these tools on their own and bring that feedback up on the
> mailing list. In that case you've taken the responsibility to actually
> verify the validity (or at least the likely validity) of the issues the
> AI pointed out. I certainly would have no issue with that and
> appreciate the issue being brought up. I know a number of my coworkers
> do this, and I've honestly not had any issues with it.
>
> That's all, I'd love if this was opt-in - and not enabled for the
> entire mailing list. Thank you.

I agree that this kind of tool should be opt-in. Maybe we can make it
such as Sachiko reviews are only sent to the author of a patch if they
also Cc'd some sachiko@ address that acts as an opt-in?

Sachiko can still do reviews and post them on its web interface even
without it, but the author would not be explicitly notified in that
case.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Maybe make Sashiko emails opt-in please?
  2026-04-23  1:48 ` Alexandre Courbot
@ 2026-04-23 20:24   ` John Hubbard
  2026-04-23 22:16     ` Roman Gushchin
  0 siblings, 1 reply; 6+ messages in thread
From: John Hubbard @ 2026-04-23 20:24 UTC (permalink / raw)
  To: Alexandre Courbot, lyude; +Cc: rust-for-linux

On 4/22/26 6:48 PM, Alexandre Courbot wrote:
> On Thu Apr 23, 2026 at 10:10 AM JST, lyude wrote:
... 
> I agree that this kind of tool should be opt-in. Maybe we can make it
> such as Sachiko reviews are only sent to the author of a patch if they
> also Cc'd some sachiko@ address that acts as an opt-in?

I love the idea of Sashiko remaining silent, unless it was specifically
Cc'd.

* Developers prefer tools that can "pre-review" and catch issues *before*
they post publicly.

    * checkpatch.pl does that.
    * sashiko could do that too! It could be triggered by a direct
      email sent only to sashiko.

* While debate continues about the false positive rate of AI-powered
code reviews vs. their value, there is *no* debate that the rate is
high enough to bother a significant fraction of kernel devs. We need
to respect that and configure the tool usage to be less, well, annoying.

This is important.

> 
> Sachiko can still do reviews and post them on its web interface even
> without it, but the author would not be explicitly notified in that
> case.

Yes, exactly.

I'm very impressed with sashiko, and want to get its feedback--in select
scenarios. Not on every patchset I post. And I believe that this is a
fairly common, widespread preference.
 

thanks,
-- 
John Hubbard


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Maybe make Sashiko emails opt-in please?
  2026-04-23 20:24   ` John Hubbard
@ 2026-04-23 22:16     ` Roman Gushchin
  2026-04-24 23:22       ` Miguel Ojeda
  2026-04-26 23:38       ` Danilo Krummrich
  0 siblings, 2 replies; 6+ messages in thread
From: Roman Gushchin @ 2026-04-23 22:16 UTC (permalink / raw)
  To: John Hubbard, Miguel Ojeda; +Cc: rust-for-linux, Alexandre Courbot, lyude

Hey!

I'm totally happy to disable email delivery for rust-for-linux if Miguel
is onboard - I generally rely on maintainers for the decision how to use
Sashiko or not use at all. I have obviously zero interest in pushing it
against developers will, however it's hard to achieve a full consensus
on anything in a large group of people, so I have to prioritize maintainers
opinion.

Miguel, what do you think? I can keep you on cc, so that you will be
receiving reviews, but nobody else. That would be my personal preference
in this case.

Otherwise:
Unfortunately I can't provide Sashiko as a free service for an open set
of kernel engineers, I simple don't have a big enough budget to cover
associated compute costs. If there is some company which is willing to
cover it, we can probably set something up via LF - Sashiko as a project
belongs to LF.

I try to make it easy to set up local/corporate instances and also
try to make it work with any LLM providers. I personally only have
access to Gemini, so I'm somewhat limited in testing here and rely on
other contributors.

Thanks

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Maybe make Sashiko emails opt-in please?
  2026-04-23 22:16     ` Roman Gushchin
@ 2026-04-24 23:22       ` Miguel Ojeda
  2026-04-26 23:38       ` Danilo Krummrich
  1 sibling, 0 replies; 6+ messages in thread
From: Miguel Ojeda @ 2026-04-24 23:22 UTC (permalink / raw)
  To: Roman Gushchin
  Cc: John Hubbard, Miguel Ojeda, rust-for-linux, Alexandre Courbot,
	lyude

On Fri, Apr 24, 2026 at 12:16 AM Roman Gushchin
<roman.gushchin@linux.dev> wrote:
>
> Miguel, what do you think? I can keep you on cc, so that you will be
> receiving reviews, but nobody else. That would be my personal preference
> in this case.

When I queried about this feature, the motivation was to make authors
aware of the existence of the reports, not a fixed set of people like
maintainers (that is a good feature too, but orthogonal -- I added
myself to the Cc to clarify/help if needed).

Now, people do care about receiving unwanted email. That is why I
suggested at the same time an opt-out feature for the Cc's to Roman et
al., just like many online services provide the now-proverbial
"Unsubscribe" button.

Having said that, one thing needs to be very clear: in Linux, the
submitter of a patch is expected to defend it. And, at the same time,
anyone can submit feedback. That is how this all works -- authors
cannot block reviewers from their patches, just like no one can block
someone else from submitting a patch.

[ Of course, there are exceptions: if someone (or someone's LLM) is
actually being a troll, that is a different matter. ]

We have had bots since before LLMs were a thing too, as well as other
automated tooling. Sashiko is also already sending reports directly to
kernel mailing lists of similar size than this one.

So the main question really is whether we consider Sashiko's useful
enough or not, not so much whether it is sent to a mailing list or
not. Either the reports are worth our time, and thus it is best to get
them in people's hands as soon as possible; or they are just not worth
our collective time.

Regarding that, I asked others in the team after we had some weeks of
reports, and what I heard is that false positives could be lower (who
wouldn't want that), but that it does find real issues. We also added
prompts to Chris' repository to tweak/improve the reports and catch
more things. Roman may have more data points for the wider kernel.

And, yes, it does take time to go through Sashiko reports. That is
undeniable, but authors are also the ones best positioned to do so
since they recently wrote the patch and they are expected to
understand what they wrote (which is also, by the way, what we
actually caution people using LLMs to submit patches).

The way I see it is that if an LLM doesn't find anything of substance,
that is a *good* signal for a patch. So it goes both ways. And when it
does find something, even if it is a false positive, sometimes it does
mean the code (or the commit message) could have been clearer, e.g.
perhaps a comment is warranted (we had just a case of that).

In short, we are all trying to improve Linux here, and Google is
donating these tokens. If the system is actually wasting our time,
then we should just stop it. So far, what I heard before this thread
was that the real issues it finds are worth the pain. We will need to
decide one way or the other. This also applies to the future -- if
these LLMs get better (or worse!), then we should adjust our position.

Cheers,
Miguel

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Maybe make Sashiko emails opt-in please?
  2026-04-23 22:16     ` Roman Gushchin
  2026-04-24 23:22       ` Miguel Ojeda
@ 2026-04-26 23:38       ` Danilo Krummrich
  1 sibling, 0 replies; 6+ messages in thread
From: Danilo Krummrich @ 2026-04-26 23:38 UTC (permalink / raw)
  To: Roman Gushchin
  Cc: John Hubbard, Miguel Ojeda, rust-for-linux, Alexandre Courbot,
	lyude

On Fri Apr 24, 2026 at 12:16 AM CEST, Roman Gushchin wrote:
> I generally rely on maintainers for the decision how to use Sashiko or not use
> at all.

I think in practice, this doesn't work out. Regardless of how maintainers decide
for their subsystems, once another subsystem mailing list is involved things are
overwritten in one or the other way. This is especially true for mailing lists
such as the rust-for-linux one, which span across various subsystems.

My main concern with the current approach is that I'm worried that contributors
of the subsystems / components / drivers I maintain may immediately act on
feedback without discussing the validity of the feedback or the solution for the
problem with other people on the list first, when it is received as a private
message.

(Analogously, I would not like if for publically posted patches reviewers would
provide private feedback to the contributor.)

That said, I don't know what a solution would look like to actually make this a
maintainer decision; most likely it simply isn't possible and it has to be a
collective decision.

For me personally it would be fine if we could add a clear disclaimer upfront
that mentions that contributors should share when and how they plan to act on
the received feedback with all other recipients of the patch (series) before
acting on it (unless it is obviously trivial).

As for the opt-out, unless sashiko feedback is sent in a way that all recipients
of a patch can discuss it as necessary, any sashiko mails to me go straight into
the bin anyways, as I look things up on the website as necessary.

That said, I really like the tool and I think it provides very valuable feedback
-- thanks for working on this!

- Danilo

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2026-04-26 23:38 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-04-23  1:10 Maybe make Sashiko emails opt-in please? lyude
2026-04-23  1:48 ` Alexandre Courbot
2026-04-23 20:24   ` John Hubbard
2026-04-23 22:16     ` Roman Gushchin
2026-04-24 23:22       ` Miguel Ojeda
2026-04-26 23:38       ` Danilo Krummrich

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox