Re: Linking Patchwork with Sashiko?

Re: Linking Patchwork with Sashiko?

[Mauro Carvalho Chehab]

Hi Derek/Konstantin/Roman,

On Fri, 29 May 2026 11:28:29 -0400
Derek Barbosa <debarbos@redhat.com> wrote:

> Hi!
> 
> > 
> > Forgot to mention, but at least on media patchwork, the best is for
> > Sashiko to send an e-mail that would allow a local script to run it. 
> > 
> > The rationale is that patchwork permissions aren't fine-grained: only
> > an user with a project maintainer token can update checks. Granting
> > such permission would allow other changes at the repository, like
> > delegating a patch, archiving it or changing its status.
> > 
> 
> Thanks for the note. It will take me a minute-or-two to get up to speed here.
> I'll reach out for any clarifying questions if that's OK :^)

I added a bot parsing tool at:
	https://github.com/mchehab/pw_tools

And ran it at the maildir with linux-media e-mails I have locally.
It is currently set to parse e-mails from:

	- LKP;
	- Sysbot;
	- Sashiko.

You can see the results at:
	https://patchwork.linuxtv.org/project/linux-media/list/

(most of the warnings there are from my parser)

And this is how it looks when a patch with bot results is opened:
	https://patchwork.linuxtv.org/project/linux-media/patch/20260529-milos-iris-v2-2-7a763d7195ae@pm.me/

I didn't set yet any daemon to keep this updated. As I used my own
token, all contexts were marked with my own ID.

There is one issue with the current process: if there aren't any
warnings on a patch, like on this example:

	https://patchwork.linuxtv.org/project/linux-media/patch/20260529154357.18066-1-mohan86108@gmail.com/

There's no way to tell if Sashiko tested such patch or not. As I
commented with Roman in a private discussion, ideally the best
would be if Sashiko could produce a single per-patch-series email
that would have something similar to this:

	Subject: Re: [PATCH v3 00/13] Improve process/maintainers output
 	Reply-to: <some_id>
 
 	Hi,
 
 	Sashiko robot found the following potencial issues:

	Patch 1/13 (<message_id): Success
	Patch 2/13 (<message_id): Success
	Patch 3/13 (<message_id): Success
	Patch 4/13 (<message_id): Success
	Patch 5/13 (<message_id): Success

 	Patch 6/13 (<message_id): Warning: https://sashiko.dev/#/patchset/...
	- [Low] The `self.field_prev` variable is assigned but never used
	...

	Patch 13/13: Success

 	Please check if those issues are pertinent.
  
 	Sashiko AI review 

E.g. it would contain success and warning status for each message
ID inside a patch series. This is also ideal for me as a maintainer,
as I can clearly see the low/mid/high issues detected by sashiko
on a single e-mail.

Thanks,
Mauro

Re: Linking Patchwork with Sashiko?

[Roman Gushchin]

Hi Mauro!

My understanding is that some subsystems might be interested in having patchwork integration 
without Sashiko sending reviews over the email. Most notable, net. Also mptcp.

Thanks!

> On May 30, 2026, at 1:30 AM, Mauro Carvalho Chehab <mchehab+huawei@kernel.org> wrote:
> 
> Hi Derek/Konstantin/Roman,
> 
>> On Fri, 29 May 2026 11:28:29 -0400
>> Derek Barbosa <debarbos@redhat.com> wrote:
>> 
>> Hi!
>> 
>>> 
>>> Forgot to mention, but at least on media patchwork, the best is for
>>> Sashiko to send an e-mail that would allow a local script to run it.
>>> 
>>> The rationale is that patchwork permissions aren't fine-grained: only
>>> an user with a project maintainer token can update checks. Granting
>>> such permission would allow other changes at the repository, like
>>> delegating a patch, archiving it or changing its status.
>>> 
>> 
>> Thanks for the note. It will take me a minute-or-two to get up to speed here.
>> I'll reach out for any clarifying questions if that's OK :^)
> 
> I added a bot parsing tool at:
>    https://github.com/mchehab/pw_tools
> 
> And ran it at the maildir with linux-media e-mails I have locally.
> It is currently set to parse e-mails from:
> 
>    - LKP;
>    - Sysbot;
>    - Sashiko.
> 
> You can see the results at:
>    https://patchwork.linuxtv.org/project/linux-media/list/
> 
> (most of the warnings there are from my parser)
> 
> And this is how it looks when a patch with bot results is opened:
>    https://patchwork.linuxtv.org/project/linux-media/patch/20260529-milos-iris-v2-2-7a763d7195ae@pm.me/
> 
> I didn't set yet any daemon to keep this updated. As I used my own
> token, all contexts were marked with my own ID.
> 
> There is one issue with the current process: if there aren't any
> warnings on a patch, like on this example:
> 
>    https://patchwork.linuxtv.org/project/linux-media/patch/20260529154357.18066-1-mohan86108@gmail.com/
> 
> There's no way to tell if Sashiko tested such patch or not. As I
> commented with Roman in a private discussion, ideally the best
> would be if Sashiko could produce a single per-patch-series email
> that would have something similar to this:
> 
>    Subject: Re: [PATCH v3 00/13] Improve process/maintainers output
>    Reply-to: <some_id>
> 
>    Hi,
> 
>    Sashiko robot found the following potencial issues:
> 
>    Patch 1/13 (<message_id): Success
>    Patch 2/13 (<message_id): Success
>    Patch 3/13 (<message_id): Success
>    Patch 4/13 (<message_id): Success
>    Patch 5/13 (<message_id): Success
> 
>    Patch 6/13 (<message_id): Warning: https://sashiko.dev/#/patchset/...
>    - [Low] The `self.field_prev` variable is assigned but never used
>    ...
> 
>    Patch 13/13: Success
> 
>    Please check if those issues are pertinent.
> 
>    Sashiko AI review
> 
> E.g. it would contain success and warning status for each message
> ID inside a patch series. This is also ideal for me as a maintainer,
> as I can clearly see the low/mid/high issues detected by sashiko
> on a single e-mail.
> 
> Thanks,
> Mauro

Re: Linking Patchwork with Sashiko?

[Mauro Carvalho Chehab]

On Sat, 30 May 2026 08:57:13 -0700
Roman Gushchin <roman.gushchin@linux.dev> wrote:

> Hi Mauro!
> 
> My understanding is that some subsystems might be interested in having patchwork integration 
> without Sashiko sending reviews over the email. Most notable, net. Also mptcp.

Well, you can use my scripts to do such integration
(https://github.com/mchehab/pw_tools).

Yet, you'll need a patchwork token with full project permission to add
a new check - e.g. it would allow Sachiko to not only change checks. 
Such token will have all project grants including status and delegation
changes.

Anyway, for subsystems that prefer a direct integration and provide
you a write token, you can let sashiko to run my script - or call directly
the Python class on it - letting it update status directly. You'll
probably need to implement a queue to do retries, in case patchwork
server has issues by the time it tries to update.

For media, I prefer a single e-mail, sent to a separate e-mail, to
reduce e-mail traffic at the main ML. This way, we can let such script
do just check changes - and use the same process to also handle other
bots like sysbot and LKP.

Also, emails are asynchronous, and, in case of problems, one can repeat
the operation later using a ML archive to re-run the email queue. 

> 
> Thanks!
> 
> > On May 30, 2026, at 1:30 AM, Mauro Carvalho Chehab <mchehab+huawei@kernel.org> wrote:
> > 
> > Hi Derek/Konstantin/Roman,
> >   
> >> On Fri, 29 May 2026 11:28:29 -0400
> >> Derek Barbosa <debarbos@redhat.com> wrote:
> >> 
> >> Hi!
> >>   
> >>> 
> >>> Forgot to mention, but at least on media patchwork, the best is for
> >>> Sashiko to send an e-mail that would allow a local script to run it.
> >>> 
> >>> The rationale is that patchwork permissions aren't fine-grained: only
> >>> an user with a project maintainer token can update checks. Granting
> >>> such permission would allow other changes at the repository, like
> >>> delegating a patch, archiving it or changing its status.
> >>>   
> >> 
> >> Thanks for the note. It will take me a minute-or-two to get up to speed here.
> >> I'll reach out for any clarifying questions if that's OK :^)  
> > 
> > I added a bot parsing tool at:
> >    https://github.com/mchehab/pw_tools
> > 
> > And ran it at the maildir with linux-media e-mails I have locally.
> > It is currently set to parse e-mails from:
> > 
> >    - LKP;
> >    - Sysbot;
> >    - Sashiko.
> > 
> > You can see the results at:
> >    https://patchwork.linuxtv.org/project/linux-media/list/
> > 
> > (most of the warnings there are from my parser)
> > 
> > And this is how it looks when a patch with bot results is opened:
> >    https://patchwork.linuxtv.org/project/linux-media/patch/20260529-milos-iris-v2-2-7a763d7195ae@pm.me/
> > 
> > I didn't set yet any daemon to keep this updated. As I used my own
> > token, all contexts were marked with my own ID.
> > 
> > There is one issue with the current process: if there aren't any
> > warnings on a patch, like on this example:
> > 
> >    https://patchwork.linuxtv.org/project/linux-media/patch/20260529154357.18066-1-mohan86108@gmail.com/
> > 
> > There's no way to tell if Sashiko tested such patch or not. As I
> > commented with Roman in a private discussion, ideally the best
> > would be if Sashiko could produce a single per-patch-series email
> > that would have something similar to this:
> > 
> >    Subject: Re: [PATCH v3 00/13] Improve process/maintainers output
> >    Reply-to: <some_id>
> > 
> >    Hi,
> > 
> >    Sashiko robot found the following potencial issues:
> > 
> >    Patch 1/13 (<message_id): Success
> >    Patch 2/13 (<message_id): Success
> >    Patch 3/13 (<message_id): Success
> >    Patch 4/13 (<message_id): Success
> >    Patch 5/13 (<message_id): Success
> > 
> >    Patch 6/13 (<message_id): Warning: https://sashiko.dev/#/patchset/...
> >    - [Low] The `self.field_prev` variable is assigned but never used
> >    ...
> > 
> >    Patch 13/13: Success
> > 
> >    Please check if those issues are pertinent.
> > 
> >    Sashiko AI review
> > 
> > E.g. it would contain success and warning status for each message
> > ID inside a patch series. This is also ideal for me as a maintainer,
> > as I can clearly see the low/mid/high issues detected by sashiko
> > on a single e-mail.
> > 
> > Thanks,
> > Mauro  



Thanks,
Mauro

Re: Linking Patchwork with Sashiko?

[Mauro Carvalho Chehab]

On Sat, 30 May 2026 20:00:17 +0200
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> wrote:

> On Sat, 30 May 2026 08:57:13 -0700
> Roman Gushchin <roman.gushchin@linux.dev> wrote:
> 
> > Hi Mauro!
> > 
> > My understanding is that some subsystems might be interested in having patchwork integration 
> > without Sashiko sending reviews over the email. Most notable, net. Also mptcp.  
> 
> Well, you can use my scripts to do such integration
> (https://github.com/mchehab/pw_tools).

Btw, I'm running my script here, making it use kernel.org. On some
patches that are c/c to media, I can update status with my user,
as I'm marked as maintainer there, like on those:

	https://patchwork.kernel.org/project/linux-media/patch/20251220192210.399423-1-szymonwilczek@gmx.com/
	https://patchwork.kernel.org/project/linux-media/patch/bf19e526-3327-46a5-8ecd-4baaadef5bcf@I-love.SAKURA.ne.jp/

but on others, it fails:

	ERROR: 14589154: sashiko failed to set 'warning': 403 Client Error: Forbidden for url: https://patchwork.kernel.org/api/patches/14589154/checks/

In total, it was able to update 160 patches. At the media instance,
~230 patches were updated using the same maildir directory.

Looking on this patch, for instance:
	https://patchwork.kernel.org/project/linux-media/patch/20260530143541.229628-3-phasta@kernel.org/
	https://patchwork.linuxtv.org/project/linux-media/patch/20260530143541.229628-3-phasta@kernel.org/

(patch is actually for Rust, but it was c/c to linux-media,
so it appears at linux-media project)

and on this:
	https://patchwork.kernel.org/project/linux-media/patch/20260530094326.11892-2-linux.amoon@gmail.com/
	https://patchwork.linuxtv.org/project/linux-media/patch/20260530094326.11892-2-linux.amoon@gmail.com/

(patch is actually for linux-media, but was c/c to other
mailing lists as well)

Both were updated on linuxtv.org (as there's just one Kernel project
there), but they were not updated at kernel.org. What I *suspect* is
that patches which are copied to multiple e-mails are problematic.

Thanks,
Mauro

Re: Linking Patchwork with Sashiko?

[Mauro Carvalho Chehab]

On Sat, 30 May 2026 20:49:45 +0200
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> wrote:

> On Sat, 30 May 2026 20:00:17 +0200
> Mauro Carvalho Chehab <mchehab+huawei@kernel.org> wrote:
> 
> > On Sat, 30 May 2026 08:57:13 -0700
> > Roman Gushchin <roman.gushchin@linux.dev> wrote:
> >   
> > > Hi Mauro!
> > > 
> > > My understanding is that some subsystems might be interested in having patchwork integration 
> > > without Sashiko sending reviews over the email. Most notable, net. Also mptcp.    
> > 
> > Well, you can use my scripts to do such integration
> > (https://github.com/mchehab/pw_tools).  
> 
> Btw, I'm running my script here, making it use kernel.org. On some
> patches that are c/c to media, I can update status with my user,
> as I'm marked as maintainer there, like on those:
> 
> 	https://patchwork.kernel.org/project/linux-media/patch/20251220192210.399423-1-szymonwilczek@gmx.com/
> 	https://patchwork.kernel.org/project/linux-media/patch/bf19e526-3327-46a5-8ecd-4baaadef5bcf@I-love.SAKURA.ne.jp/
> 
> but on others, it fails:
> 
> 	ERROR: 14589154: sashiko failed to set 'warning': 403 Client Error: Forbidden for url: https://patchwork.kernel.org/api/patches/14589154/checks/
> 
> In total, it was able to update 160 patches. At the media instance,
> ~230 patches were updated using the same maildir directory.
> 
> Looking on this patch, for instance:
> 	https://patchwork.kernel.org/project/linux-media/patch/20260530143541.229628-3-phasta@kernel.org/
> 	https://patchwork.linuxtv.org/project/linux-media/patch/20260530143541.229628-3-phasta@kernel.org/
> 
> (patch is actually for Rust, but it was c/c to linux-media,
> so it appears at linux-media project)
> 
> and on this:
> 	https://patchwork.kernel.org/project/linux-media/patch/20260530094326.11892-2-linux.amoon@gmail.com/
> 	https://patchwork.linuxtv.org/project/linux-media/patch/20260530094326.11892-2-linux.amoon@gmail.com/
> 
> (patch is actually for linux-media, but was c/c to other
> mailing lists as well)
> 
> Both were updated on linuxtv.org (as there's just one Kernel project
> there), but they were not updated at kernel.org. What I *suspect* is
> that patches which are copied to multiple e-mails are problematic.

In time: problematic in the sense that the first project that
picked it is likely the patch "owner": the token will require
maintainership on such project.

In practice it would mean that the token used on patchwork instances
with multiple Kernel projects may need maintainers permission on all
such projects, as otherwise patchwork update will fail.

Thanks,
Mauro

Re: Linking Patchwork with Sashiko?

[Derek Barbosa]

On Sat, May 30, 2026 at 08:53:51PM +0200, Mauro Carvalho Chehab wrote:
> 
> In time: problematic in the sense that the first project that
> picked it is likely the patch "owner": the token will require
> maintainership on such project.
> 
> In practice it would mean that the token used on patchwork instances
> with multiple Kernel projects may need maintainers permission on all
> such projects, as otherwise patchwork update will fail.
> 
> Thanks,
> Mauro
> 

Hi Mauro,

Just to recap the the thread, to confirm that I am following it correctly:

- Patchwork only supports a single URL mask for message-ID lookup (lore or
  sashiko). Adding a sashiko link would require diverging from upstream.

- pw_tools is a workaround solution to get/set status on patchwork via bot-mail
  parsing. pw tokens also have broad permission scope.

which that leaves us with two "methods" of integration:

1. The Sashiko daemon calls the pw_tools script directly to update the status.
2. Sashiko sends a single-per-patch-email with parseable "status" to a mailing
list, where some running daemon will pickup the mail.

please correct me if I am wrong here :)

Roman, for 1, do we want to dip our toes into FFI for the provided pw_tools
python script, or would a more general std::process::* subprocess suffice?

Alternatively, we could just translate the logic into Rust, gated behind a
config. I will have to think about how we would like to implement retry-queues.

Thinking out loud: would it be simpler to "tag" the reviews that require a
patchwork-status-update in the DB, and let a cronjob handle setting patchwork
state? updating the candidates that have successfully posted?

Anyway, Mauro, I think we have the capacity to tackle both patchwork integration
methods. Would exposing a configuration in the email_policy file that allowed
for mailing lists to specify what type of patchwork integration suffice?

This way, a mailing list that would want patchwork integration can opt for
either the single email approach (as you described) or through the API?

something like:

[subsystems.linux-media]
lists = ["linux-media@vger.kernel.org"]
reply_to_author = true
cc = ["linux-media@vger.kernel.org"]
+ # optional value can be set to email or API
+ patchwork = "email"

Roman is currently working through how "subsystems" are detected via Sashiko,
taking inspiration from the get_maintainer.pl script. This may help with some of
the concerns I saw with patches-meant-for-other mailing lists?

Cheers,
-- 
Derek <debarbos@redhat.com>

Re: Linking Patchwork with Sashiko?

[Mauro Carvalho Chehab]

On Tue, 2 Jun 2026 11:51:42 -0400
Derek Barbosa <debarbos@redhat.com> wrote:

> On Sat, May 30, 2026 at 08:53:51PM +0200, Mauro Carvalho Chehab wrote:
> > 
> > In time: problematic in the sense that the first project that
> > picked it is likely the patch "owner": the token will require
> > maintainership on such project.
> > 
> > In practice it would mean that the token used on patchwork instances
> > with multiple Kernel projects may need maintainers permission on all
> > such projects, as otherwise patchwork update will fail.
> > 
> > Thanks,
> > Mauro
> >   
> 
> Hi Mauro,
> 
> Just to recap the the thread, to confirm that I am following it correctly:
> 
> - Patchwork only supports a single URL mask for message-ID lookup (lore or
>   sashiko). Adding a sashiko link would require diverging from upstream.

Not sure what you mean.

AFAIKT, a RFC-822 application can have just one message-ID per message.

For message lookup, patchwork works using its own patch ID, or via a search
to the original message ID that contains the patch. So, no, it won't be lore
nor sashiko, as neither lore nor sashiko write e-mails ;-)

If you're talking instead about CI reports, patchwork does support multiple
sources.

See for instance:
	https://patchwork.linuxtv.org/project/linux-media/patch/20260531-qcom-cphy-v5-8-6be0f62b4d65@ixit.cz/

There, media-ci does update it directly via rest protocol; Sashiko
(and LKP/Sysbot) messages are handled by inspecting e-mails using
pw_tools.

> - pw_tools is a workaround solution to get/set status on patchwork via bot-mail
>   parsing. pw tokens also have broad permission scope.

pw_tools is not a workaround solution. It is client tools implementing 
Patchwork's REST protocol. You can use it or whatever other client you
want. If you decide using it, feel free to send me patches improving it
as needed.

> which that leaves us with two "methods" of integration:
> 
> 1. The Sashiko daemon calls the pw_tools script directly to update the status.
> 2. Sashiko sends a single-per-patch-email with parseable "status" to a mailing
> list, where some running daemon will pickup the mail.
>
> please correct me if I am wrong here :)

There is a third option, which is what I currently implemented at:
	https://patchwork.linuxtv.org/project/linux-media/list/

3. Parse the e-mails already sent by Sashiko, before/after patchwork's
   e-mail job process.

The problem with (3) is that it will only pick Sashiko's warning
e-mails, as success doesn't generate e-mails. The alternative of sending
e-mails also for success doesn't scale, as nobody wants that every
possible bot out would send success messages to them. Those are OK
to just update CI context display.

That's why, on media, we do prefer (2), preferably sending e-mails
to a separate e-mail that won't be adding it to the mailing list.

> Roman, for 1, do we want to dip our toes into FFI for the provided pw_tools
> python script, or would a more general std::process::* subprocess suffice?
> 
> Alternatively, we could just translate the logic into Rust, gated behind a
> config. I will have to think about how we would like to implement retry-queues.

Certainly if you decide to do that, you'll need to have retry-queues and
eventually some traffic-flow control to avoid too heavy workloads at
patchwork's side.

> Thinking out loud: would it be simpler to "tag" the reviews that require a
> patchwork-status-update in the DB, and let a cronjob handle setting patchwork
> state? updating the candidates that have successfully posted?

Patchwork handles e-mail sending this way.

> Anyway, Mauro, I think we have the capacity to tackle both patchwork integration
> methods. Would exposing a configuration in the email_policy file that allowed
> for mailing lists to specify what type of patchwork integration suffice?
> 
> This way, a mailing list that would want patchwork integration can opt for
> either the single email approach (as you described) or through the API?

Makes sense.

> something like:
> 
> [subsystems.linux-media]
> lists = ["linux-media@vger.kernel.org"]
> reply_to_author = true
> cc = ["linux-media@vger.kernel.org"]
> + # optional value can be set to email or API
> + patchwork = "email"

works for me, but I would, instead do something like this:

	patchwork = "email:a-bot-status-update-email@linuxtv.org"

to let one specify a different e-mail address to handle context
updates, thus reducing ML traffic.

> Roman is currently working through how "subsystems" are detected via Sashiko,
> taking inspiration from the get_maintainer.pl script. 

You could also take a look at:
	Documentation/sphinx/maintainers_include.py

The parser there converts maintainer entries into a dict, which
can make it easier to use, specially when you want to handle
multiple subsystems.

> This may help with some of
> the concerns I saw with patches-meant-for-other mailing lists?

Yes. Btw, in the specific case of projects using patchwork@kernel.org
(or any other instance with multiple Kernel projects), the user which
updates CI status information has to be maintainer on *all* kernel
projects, as otherwise some/several patches won't be updated.

Basically, when a message is c/c to multiple mailing lists, just one
of such mailing list will "own" the patch. Only a Django user with
permission at the owner list can update it.

Thanks,
Mauro

Re: Linking Patchwork with Sashiko?

[Jason Gunthorpe]

On Tue, Jun 02, 2026 at 06:51:15PM +0200, Mauro Carvalho Chehab wrote:
> On Tue, 2 Jun 2026 11:51:42 -0400
> Derek Barbosa <debarbos@redhat.com> wrote:
> 
> > On Sat, May 30, 2026 at 08:53:51PM +0200, Mauro Carvalho Chehab wrote:
> > > 
> > > In time: problematic in the sense that the first project that
> > > picked it is likely the patch "owner": the token will require
> > > maintainership on such project.
> > > 
> > > In practice it would mean that the token used on patchwork instances
> > > with multiple Kernel projects may need maintainers permission on all
> > > such projects, as otherwise patchwork update will fail.
> > > 
> > > Thanks,
> > > Mauro
> > >   
> > 
> > Hi Mauro,
> > 
> > Just to recap the the thread, to confirm that I am following it correctly:
> > 
> > - Patchwork only supports a single URL mask for message-ID lookup (lore or
> >   sashiko). Adding a sashiko link would require diverging from upstream.
> 
> Not sure what you mean.
> 
> AFAIKT, a RFC-822 application can have just one message-ID per message.
> 
> For message lookup, patchwork works using its own patch ID, or via a search
> to the original message ID that contains the patch. So, no, it won't be lore
> nor sashiko, as neither lore nor sashiko write e-mails ;-)

He means the hyperlink patchworks adds, ie look here:

https://patchwork.kernel.org/project/linux-rdma/patch/20260602140453.3542427-1-arnd@kernel.org/

See the near top of the page "Message ID" section 

Message ID	20260602140453.3542427-1-arnd@kernel.org (mailing list archive)
                                                           ^^^^^^^^^^^^^^^^^^

That hyperlink goes to lore, Kostantin set this up

What I suggested as a very basic first step is a second hyperlink to
Sashiko, which I guess needs upstream to adjust how they generate this
html.

Integrating as CI reports and so on would be nice if someone can
manage it for all the kernel.org patchworks :)

Jason

Re: Linking Patchwork with Sashiko?

[Mauro Carvalho Chehab]

On Tue, 2 Jun 2026 15:39:55 -0300
Jason Gunthorpe <jgg@ziepe.ca> wrote:

> On Tue, Jun 02, 2026 at 06:51:15PM +0200, Mauro Carvalho Chehab wrote:
> > On Tue, 2 Jun 2026 11:51:42 -0400
> > Derek Barbosa <debarbos@redhat.com> wrote:
> >   
> > > On Sat, May 30, 2026 at 08:53:51PM +0200, Mauro Carvalho Chehab wrote:  
> > > > 
> > > > In time: problematic in the sense that the first project that
> > > > picked it is likely the patch "owner": the token will require
> > > > maintainership on such project.
> > > > 
> > > > In practice it would mean that the token used on patchwork instances
> > > > with multiple Kernel projects may need maintainers permission on all
> > > > such projects, as otherwise patchwork update will fail.
> > > > 
> > > > Thanks,
> > > > Mauro
> > > >     
> > > 
> > > Hi Mauro,
> > > 
> > > Just to recap the the thread, to confirm that I am following it correctly:
> > > 
> > > - Patchwork only supports a single URL mask for message-ID lookup (lore or
> > >   sashiko). Adding a sashiko link would require diverging from upstream.  
> > 
> > Not sure what you mean.
> > 
> > AFAIKT, a RFC-822 application can have just one message-ID per message.
> > 
> > For message lookup, patchwork works using its own patch ID, or via a search
> > to the original message ID that contains the patch. So, no, it won't be lore
> > nor sashiko, as neither lore nor sashiko write e-mails ;-)  
> 
> He means the hyperlink patchworks adds, ie look here:
> 
> https://patchwork.kernel.org/project/linux-rdma/patch/20260602140453.3542427-1-arnd@kernel.org/
> 
> See the near top of the page "Message ID" section 
> 
> Message ID	20260602140453.3542427-1-arnd@kernel.org (mailing list archive)
>                                                            ^^^^^^^^^^^^^^^^^^
> 
> That hyperlink goes to lore, Kostantin set this up
> 
> What I suggested as a very basic first step is a second hyperlink to
> Sashiko, which I guess needs upstream to adjust how they generate this
> html.

If you want exactly like that, it would require patchwork changes(*), but
see that CI checks context have their own link as well, like here:

(*) to be more precise, it will require changing an html template 
    (templates/patchwork/submission.html). There it says how a patch
     is shown.

    The message ID part is like this:

	{% for sibling in submission.series.patches.all %}
            <li>
	{% if sibling == submission %}
                {{ sibling.name|default:"[no subject]"|truncatechars:100 }}
	{% else %}
              <a href="{% url 'patch-detail' project_id=project.linkname msgid=sibling.encoded_msgid %}">
                {{ sibling.name|default:"[no subject]"|truncatechars:100 }}
              </a>
	{% endif %}
            </li>

	...

    And the CI checks are:
	
	{% if checks %}
	<h2>Checks</h2>
	<table class="checks">
	<tr>  
	  <th>Context</th>
	  <th>Check</th>
	  <th>Description</th>
	</tr> 
	{% for check in checks %}
	<tr>  
	  <td>{{ check.user }}/{{ check.context }}</td>
	  <td>
	    <span title="Updated {{ check.date|naturaltime }}" class="state {{ check.get_state_display }}">
	      {{ check.get_state_display }}
	    </span>
	  </td>
	  <td>
	{% if check.target_url %}
	    <a href="{{ check.target_url }}">
	{% endif %}
	    {{ check.description }}
	{% if check.target_url %}
	    </a>
	{% endif %}
	  </td>
	</tr>
	{% endfor %}
	</table>
	{% endif %}	

Yet, if you see how the above template is parsed, here, for instance:
	https://patchwork.linuxtv.org/project/linux-media/patch/20260530143541.229628-4-phasta@kernel.org/

Btw, on media patchwork, we're using Patchwork v3.2.1 as is, with just one 
or two fix patches on the top of it (and with series patch from an upstream 
PR merged) and no template changes.

You'll see there that media-ci added 4 contexts to this patch, 
each with its own link URL (all descriptions there are "Link").
Each {target_url} field there goes directly to the media-ci logs.

My bot added just one for sashiko (and if we had LKP and/or
sysbot for the same patch, it would be shown there as well as
separate lines). 

As this came from an unsigned e-mail, I'm opting to place there
a link to lore, as it already sanitizes URLs, hopefully avoiding them
to point to some malicious site.

I might have placed instead a link to sashiko CI output, but on
such case, I would like require a gpg signature to validate the e-mail
content, as adding links received by e-mail without first validating
its origin is not good from security point of view.

> Integrating as CI reports and so on would be nice if someone can
> manage it for all the kernel.org patchworks :)

No idea what you meant as "CI reports", and what this is different
from what we have today already implemented on patchwork.

Thanks,
Mauro

Re: Linking Patchwork with Sashiko?

[Roman Gushchin]

Derek Barbosa <debarbos@redhat.com> writes:

> On Sat, May 30, 2026 at 08:53:51PM +0200, Mauro Carvalho Chehab wrote:
>> 
>> In time: problematic in the sense that the first project that
>> picked it is likely the patch "owner": the token will require
>> maintainership on such project.
>> 
>> In practice it would mean that the token used on patchwork instances
>> with multiple Kernel projects may need maintainers permission on all
>> such projects, as otherwise patchwork update will fail.
>> 
>> Thanks,
>> Mauro
>> 
>
> Hi Mauro,
>
> Just to recap the the thread, to confirm that I am following it correctly:
>
> - Patchwork only supports a single URL mask for message-ID lookup (lore or
>   sashiko). Adding a sashiko link would require diverging from
> upstream.

Is it something we can change upstream?

>
> - pw_tools is a workaround solution to get/set status on patchwork via bot-mail
>   parsing. pw tokens also have broad permission scope.
>
> which that leaves us with two "methods" of integration:
>
> 1. The Sashiko daemon calls the pw_tools script directly to update the status.
> 2. Sashiko sends a single-per-patch-email with parseable "status" to a mailing
> list, where some running daemon will pickup the mail.

This feels a bit hacky.

> please correct me if I am wrong here :)
>
> Roman, for 1, do we want to dip our toes into FFI for the provided pw_tools
> python script, or would a more general std::process::* subprocess suffice?
>
> Alternatively, we could just translate the logic into Rust, gated behind a
> config. I will have to think about how we would like to implement
> retry-queues.

I strongly prefer the option with implementing the logic in Rust.

> Thinking out loud: would it be simpler to "tag" the reviews that require a
> patchwork-status-update in the DB, and let a cronjob handle setting patchwork
> state? updating the candidates that have successfully posted?

We have already a well working logic for sending emails, we can more or
less duplicate it for patchwork.


Thanks

Re: Linking Patchwork with Sashiko?

[Mauro Carvalho Chehab]

On Tue, 02 Jun 2026 20:13:15 +0000
Roman Gushchin <roman.gushchin@linux.dev> wrote:

> Derek Barbosa <debarbos@redhat.com> writes:
> 
> > On Sat, May 30, 2026 at 08:53:51PM +0200, Mauro Carvalho Chehab wrote:  
> >> 
> >> In time: problematic in the sense that the first project that
> >> picked it is likely the patch "owner": the token will require
> >> maintainership on such project.
> >> 
> >> In practice it would mean that the token used on patchwork instances
> >> with multiple Kernel projects may need maintainers permission on all
> >> such projects, as otherwise patchwork update will fail.
> >> 
> >> Thanks,
> >> Mauro
> >>   
> >
> > Hi Mauro,
> >
> > Just to recap the the thread, to confirm that I am following it correctly:
> >
> > - Patchwork only supports a single URL mask for message-ID lookup (lore or
> >   sashiko). Adding a sashiko link would require diverging from
> > upstream.  
> 
> Is it something we can change upstream?

No idea. I suspect a change like that will require change patches database
and use Django's migration logic to touch its database.

However, at least for me, I can't see any value of being able search for a
patch based on Sashiko's message ID.

> > - pw_tools is a workaround solution to get/set status on patchwork via bot-mail
> >   parsing. pw tokens also have broad permission scope.
> >
> > which that leaves us with two "methods" of integration:
> >
> > 1. The Sashiko daemon calls the pw_tools script directly to update the status.
> > 2. Sashiko sends a single-per-patch-email with parseable "status" to a mailing
> > list, where some running daemon will pickup the mail.  
> 
> This feels a bit hacky.

The alternative that would be acceptable, at least on media, is if 
one would add support on patchwork to have a separate permission just
for checks update.

Granting full maintainership control to external bots sounds too risky 
for my taste.


Thanks,
Mauro

Re: Linking Patchwork with Sashiko?

[Roman Gushchin]

Mauro Carvalho Chehab <mchehab+huawei@kernel.org> writes:

> On Tue, 02 Jun 2026 20:13:15 +0000
> Roman Gushchin <roman.gushchin@linux.dev> wrote:
>
>> Derek Barbosa <debarbos@redhat.com> writes:
>> 
>> > On Sat, May 30, 2026 at 08:53:51PM +0200, Mauro Carvalho Chehab wrote:  
>> >> 
>> >> In time: problematic in the sense that the first project that
>> >> picked it is likely the patch "owner": the token will require
>> >> maintainership on such project.
>> >> 
>> >> In practice it would mean that the token used on patchwork instances
>> >> with multiple Kernel projects may need maintainers permission on all
>> >> such projects, as otherwise patchwork update will fail.
>> >> 
>> >> Thanks,
>> >> Mauro
>> >>   
>> >
>> > Hi Mauro,
>> >
>> > Just to recap the the thread, to confirm that I am following it correctly:
>> >
>> > - Patchwork only supports a single URL mask for message-ID lookup (lore or
>> >   sashiko). Adding a sashiko link would require diverging from
>> > upstream.  
>> 
>> Is it something we can change upstream?
>
> No idea. I suspect a change like that will require change patches database
> and use Django's migration logic to touch its database.
>
> However, at least for me, I can't see any value of being able search for a
> patch based on Sashiko's message ID.
>
>> > - pw_tools is a workaround solution to get/set status on patchwork via bot-mail
>> >   parsing. pw tokens also have broad permission scope.
>> >
>> > which that leaves us with two "methods" of integration:
>> >
>> > 1. The Sashiko daemon calls the pw_tools script directly to update the status.
>> > 2. Sashiko sends a single-per-patch-email with parseable "status" to a mailing
>> > list, where some running daemon will pickup the mail.  
>> 
>> This feels a bit hacky.
>
> The alternative that would be acceptable, at least on media, is if 
> one would add support on patchwork to have a separate permission just
> for checks update.

Agree, it feels like the best way forward.

> Granting full maintainership control to external bots sounds too risky 
> for my taste.

Agree. I'd strongly prefer Sashiko to not have it.

Re: Linking Patchwork with Sashiko?

[Matthieu Baerts]

Hi Mauro, Derek, Roman,

On 03/06/2026 06:39, Mauro Carvalho Chehab wrote:
> On Tue, 02 Jun 2026 20:13:15 +0000
> Roman Gushchin <roman.gushchin@linux.dev> wrote:
>> Derek Barbosa <debarbos@redhat.com> writes:
>>> On Sat, May 30, 2026 at 08:53:51PM +0200, Mauro Carvalho Chehab wrote:  

(...)

>>> - pw_tools is a workaround solution to get/set status on patchwork via bot-mail
>>>   parsing. pw tokens also have broad permission scope.
>>>
>>> which that leaves us with two "methods" of integration:
>>>
>>> 1. The Sashiko daemon calls the pw_tools script directly to update the status.
>>> 2. Sashiko sends a single-per-patch-email with parseable "status" to a mailing
>>> list, where some running daemon will pickup the mail.  
>>
>> This feels a bit hacky.
> 
> The alternative that would be acceptable, at least on media, is if 
> one would add support on patchwork to have a separate permission just
> for checks update.

Indeed. It looks like there is an old feature request about that:

  https://github.com/getpatchwork/patchwork/issues/14

Linked to Mauro's email from Dec 2015 :)

> Granting full maintainership control to external bots sounds too risky 
> for my taste.

Even if I agree that's not idea, I would trust Roman's and his team not
to mess-up with the project I maintain in Patchwork. I don't know when
permissions will be more modular on Patchwork. That would be different
for other services like access to the Git repo.

My current workaround is similar to Mauro: pulling Sashiko's results,
and publish them on Patchwork, e.g.

https://github.com/multipath-tcp/mptcp_net-next/blob/0c8d473f43cfab0ed926d694c77cb7824893af04/.github/workflows/tests.yml#L528-L596

But sometimes the pull timeouts, and that's not ideal, plus it needs to
be updated when Sashiko has new features, etc.


I guess Sashiko doesn't need pw_tools script if it has the permissions
to publish some results on Patchwork directly. It's just one HTTP POST
request once on the correct 'check' route, e.g.

  check_url=$(curl ${CURL_OPT} -A "${PW_AGENT}" \
      "${PW}/api/1.3/patches/?project=${PROJECT}&msgid=${MID}" |
       jq '.[].checks')

  curl ${CURL_OPT} \
      -A "${PW_AGENT}" \
      -X POST \
      -H "Authorization: Token ${PW_TOKEN}" \
      -F "state=${state}" \
      -F "target_url=https://sashiko.dev/#/patchset/${MID}" \
      -F "context=sashiko" \
      -F "description=${desc}" \
      "${check_url}"

See: https://patchwork.readthedocs.io/en/latest/usage/overview/#checks
API:
https://patchwork.readthedocs.io/en/latest/api/rest/schemas/v1.3/#post--api-1.3-patches-patch_id-checks
Ref: https://github.com/sashiko-dev/sashiko/issues/50

Cheers,
Matt
-- 
Sponsored by the NGI0 Core fund.

Re: Linking Patchwork with Sashiko?

[Mauro Carvalho Chehab]

On Wed, 3 Jun 2026 09:50:06 +1000
Matthieu Baerts <matttbe@kernel.org> wrote:

> Hi Mauro, Derek, Roman,
> 
> On 03/06/2026 06:39, Mauro Carvalho Chehab wrote:
> > On Tue, 02 Jun 2026 20:13:15 +0000
> > Roman Gushchin <roman.gushchin@linux.dev> wrote:  
> >> Derek Barbosa <debarbos@redhat.com> writes:  
> >>> On Sat, May 30, 2026 at 08:53:51PM +0200, Mauro Carvalho Chehab wrote:    
> 
> (...)
> 
> >>> - pw_tools is a workaround solution to get/set status on patchwork via bot-mail
> >>>   parsing. pw tokens also have broad permission scope.
> >>>
> >>> which that leaves us with two "methods" of integration:
> >>>
> >>> 1. The Sashiko daemon calls the pw_tools script directly to update the status.
> >>> 2. Sashiko sends a single-per-patch-email with parseable "status" to a mailing
> >>> list, where some running daemon will pickup the mail.    
> >>
> >> This feels a bit hacky.  
> > 
> > The alternative that would be acceptable, at least on media, is if 
> > one would add support on patchwork to have a separate permission just
> > for checks update.  
> 
> Indeed. It looks like there is an old feature request about that:
> 
>   https://github.com/getpatchwork/patchwork/issues/14
> 
> Linked to Mauro's email from Dec 2015 :)

Yes, this is an old request, and, as on most projects, feature 
development takes precedence over security. On that time, we wanted to 
have non-maintainer permissions to allow patch delegation. There were
more recent discussions during some Linux Media summits a couple of 
years ago, when we started implementing media-ci.

> > Granting full maintainership control to external bots sounds too risky 
> > for my taste.  
> 
> Even if I agree that's not idea, I would trust Roman's and his team not
> to mess-up with the project I maintain in Patchwork. I don't know when
> permissions will be more modular on Patchwork. That would be different
> for other services like access to the Git repo.

The problem is not trusting on people: it is trusting on a bot and
on its infra.

> My current workaround is similar to Mauro: pulling Sashiko's results,
> and publish them on Patchwork, e.g.
> 
> https://github.com/multipath-tcp/mptcp_net-next/blob/0c8d473f43cfab0ed926d694c77cb7824893af04/.github/workflows/tests.yml#L528-L596
> 
> But sometimes the pull timeouts, and that's not ideal, plus it needs to
> be updated when Sashiko has new features, etc.

That's why my model is simpler:

- handle feedback when e-mail arrives on an user's account(s) using the
  same infra that patchwork has to add patches on it. If e-mails are
  failing, patchwork won't work anyway, so there aren't any new timeout
  risks than what we had before;
- if an e-mail arrives, don't parse its content: just open a new
  context, marking as warning, so someone can later check.

---

Btw, looking on your code, you're trusting that Sashiko is properly
classifying issues.

When I was testing my new tool, I produced a broken patch by purpose,
to see if my patch would properly handle CI e-mail output:

	https://patchwork.linuxtv.org/project/linux-media/patch/9050789262f583cef777eb3a9c3e07948faf18c3.1780141190.git.mchehab+huawei@kernel.org/

If you look there, you'll see how Sashiko considered a broken
compilation patch:

	Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
	- [Low] Intentional compilation breakage via an invalid syntax token at global scope.

e.g. instead of classifying it as "High", it classified the issue
as "Low".

That's probably because, at the patch description, I mentioned that
the breakage was for testing purposes, as I didn't want devels to
waste time on it: I just wanted to pick bot answers.

In any case, the point is that one of the weakness of LLMs is that
misguided (or malicious) patch descriptions or comments can make it
do a wrong analysis and/or classification.

So, at least from my side, the best is to handle all non-success
analysis from LLM tools and from static analysis tools as warnings,
letting a human to look on it, considering the tool classification as 
just a hint.

> I guess Sashiko doesn't need pw_tools script if it has the permissions
> to publish some results on Patchwork directly. It's just one HTTP POST
> request once on the correct 'check' route, e.g.
> 
>   check_url=$(curl ${CURL_OPT} -A "${PW_AGENT}" \
>       "${PW}/api/1.3/patches/?project=${PROJECT}&msgid=${MID}" |
>        jq '.[].checks')
> 
>   curl ${CURL_OPT} \
>       -A "${PW_AGENT}" \
>       -X POST \
>       -H "Authorization: Token ${PW_TOKEN}" \
>       -F "state=${state}" \
>       -F "target_url=https://sashiko.dev/#/patchset/${MID}" \
>       -F "context=sashiko" \
>       -F "description=${desc}" \
>       "${check_url}"
> 
> See: https://patchwork.readthedocs.io/en/latest/usage/overview/#checks
> API:
> https://patchwork.readthedocs.io/en/latest/api/rest/schemas/v1.3/#post--api-1.3-patches-patch_id-checks
> Ref: https://github.com/sashiko-dev/sashiko/issues/50

Indeed it doesn't. The advantages of the script is that:
- the same script can handle different bots;
- no need to grant token maintainer's permissions to all CI
  bots;
- more control about how such token will be used, as the ones
  responsible for patchwork infra will be the ones that would be
  setting the e-mail account that will be used to update patchwork,
  and eventually storing all changes on some log.

Thanks,
Mauro

Re: Linking Patchwork with Sashiko?

[Roman Gushchin]

> On Jun 2, 2026, at 8:35 PM, Mauro Carvalho Chehab <mchehab+huawei@kernel.org> wrote:
> 
> On Wed, 3 Jun 2026 09:50:06 +1000
> Matthieu Baerts <matttbe@kernel.org> wrote:
> 
>> Hi Mauro, Derek, Roman,
>> 
>>> On 03/06/2026 06:39, Mauro Carvalho Chehab wrote:
>>> On Tue, 02 Jun 2026 20:13:15 +0000
>>> Roman Gushchin <roman.gushchin@linux.dev> wrote:  
>>>> Derek Barbosa <debarbos@redhat.com> writes:  
>>>>> On Sat, May 30, 2026 at 08:53:51PM +0200, Mauro Carvalho Chehab wrote:    
>> 
>> (...)
>> 
>>>>> - pw_tools is a workaround solution to get/set status on patchwork via bot-mail
>>>>>  parsing. pw tokens also have broad permission scope.
>>>>> 
>>>>> which that leaves us with two "methods" of integration:
>>>>> 
>>>>> 1. The Sashiko daemon calls the pw_tools script directly to update the status.
>>>>> 2. Sashiko sends a single-per-patch-email with parseable "status" to a mailing
>>>>> list, where some running daemon will pickup the mail.    
>>>> 
>>>> This feels a bit hacky.  
>>> 
>>> The alternative that would be acceptable, at least on media, is if
>>> one would add support on patchwork to have a separate permission just
>>> for checks update.  
>> 
>> Indeed. It looks like there is an old feature request about that:
>> 
>>  https://github.com/getpatchwork/patchwork/issues/14
>> 
>> Linked to Mauro's email from Dec 2015 :)
> 
> Yes, this is an old request, and, as on most projects, feature
> development takes precedence over security. On that time, we wanted to
> have non-maintainer permissions to allow patch delegation. There were
> more recent discussions during some Linux Media summits a couple of
> years ago, when we started implementing media-ci.
> 
>>> Granting full maintainership control to external bots sounds too risky
>>> for my taste.  
>> 
>> Even if I agree that's not idea, I would trust Roman's and his team not
>> to mess-up with the project I maintain in Patchwork. I don't know when
>> permissions will be more modular on Patchwork. That would be different
>> for other services like access to the Git repo.
> 
> The problem is not trusting on people: it is trusting on a bot and
> on its infra.
> 
>> My current workaround is similar to Mauro: pulling Sashiko's results,
>> and publish them on Patchwork, e.g.
>> 
>> https://github.com/multipath-tcp/mptcp_net-next/blob/0c8d473f43cfab0ed926d694c77cb7824893af04/.github/workflows/tests.yml#L528-L596
>> 
>> But sometimes the pull timeouts, and that's not ideal, plus it needs to
>> be updated when Sashiko has new features, etc.
> 
> That's why my model is simpler:
> 
> - handle feedback when e-mail arrives on an user's account(s) using the
>  same infra that patchwork has to add patches on it. If e-mails are
>  failing, patchwork won't work anyway, so there aren't any new timeout
>  risks than what we had before;
> - if an e-mail arrives, don't parse its content: just open a new
>  context, marking as warning, so someone can later check.
> 
> ---
> 
> Btw, looking on your code, you're trusting that Sashiko is properly
> classifying issues.
> 
> When I was testing my new tool, I produced a broken patch by purpose,
> to see if my patch would properly handle CI e-mail output:
> 
>    https://patchwork.linuxtv.org/project/linux-media/patch/9050789262f583cef777eb3a9c3e07948faf18c3.1780141190.git.mchehab+huawei@kernel.org/
> 
> If you look there, you'll see how Sashiko considered a broken
> compilation patch:
> 
>    Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
>    - [Low] Intentional compilation breakage via an invalid syntax token at global scope.
> 
> e.g. instead of classifying it as "High", it classified the issue
> as "Low".

It’s intentional, simple because there are better ways to find compilation issues.
So if Sashiko is right and compilation is broken, most likely the patch won’t make
it to the upstream anyway. And if Sashiko is wrong, raising a low severity false 
positive is better than a high severity false positive.
That was my logic.

Re: Linking Patchwork with Sashiko?

[Mauro Carvalho Chehab]

On Wed, 3 Jun 2026 09:50:06 +1000
Matthieu Baerts <matttbe@kernel.org> wrote:

> Hi Mauro, Derek, Roman,
> 
> On 03/06/2026 06:39, Mauro Carvalho Chehab wrote:
> > On Tue, 02 Jun 2026 20:13:15 +0000
> > Roman Gushchin <roman.gushchin@linux.dev> wrote:  
> >> Derek Barbosa <debarbos@redhat.com> writes:  
> >>> On Sat, May 30, 2026 at 08:53:51PM +0200, Mauro Carvalho Chehab wrote:    
> 
> (...)
> 
> >>> - pw_tools is a workaround solution to get/set status on patchwork via bot-mail
> >>>   parsing. pw tokens also have broad permission scope.
> >>>
> >>> which that leaves us with two "methods" of integration:
> >>>
> >>> 1. The Sashiko daemon calls the pw_tools script directly to update the status.
> >>> 2. Sashiko sends a single-per-patch-email with parseable "status" to a mailing
> >>> list, where some running daemon will pickup the mail.    
> >>
> >> This feels a bit hacky.  
> > 
> > The alternative that would be acceptable, at least on media, is if 
> > one would add support on patchwork to have a separate permission just
> > for checks update.  
> 
> Indeed. It looks like there is an old feature request about that:
> 
>   https://github.com/getpatchwork/patchwork/issues/14
> 
> Linked to Mauro's email from Dec 2015 :)

If it is OK to have a global CI permission, I think this patch
would do the trick (currently untested):

diff --git a/patchwork/api/check.py b/patchwork/api/check.py
index 74bbc19e0078..79326a96a5bb 100644
--- a/patchwork/api/check.py
+++ b/patchwork/api/check.py
@@ -108,9 +108,23 @@ class CheckListCreate(CheckMixin, ListCreateAPIView):
     lookup_url_kwarg = 'patch_id'
     ordering = 'id'
 
+    def is_editable(self, user):
+        if not user.is_authenticated:
+            return False
+
+        # Only users with add_check permission can do it.
+        # Notice that this is a global permission: it allows
+        # adding checks to any project inside Patchwork.
+        if user.has_perm('patchwork.add_check'):
+            patch._edited_by = user
+            return True
+
+        # Being maintainer doesn't grant rights to create checks.
+        return False
+
     def create(self, request, patch_id, *args, **kwargs):
         p = get_object_or_404(Patch, id=patch_id)
-        if not p.is_editable(request.user):
+        if not self.is_editable(request.user):
             raise PermissionDenied()
         request.patch = p
         return super(CheckListCreate, self).create(request, *args, **kwargs)

The idea here is to use Patchwork Django's admin screen, at
Users section, setting:

	"patchwork | check | Can add check"

Created by Django's default_permissions[1] for class Check(models.Model)
(at patchwork/models.py).

[1] https://docs.djangoproject.com/en/6.0/topics/auth/default/#default-permissions

The only issue is that the permission would be granted patchwork-wide. 
I suspect that this is probably ok for Kernel.org.

On media, we have a VDR project with is not a kernel tree and has
separate maintainers, but we don't use CI there. So, it can work
for us as well.

I'm not a django expert, but perhaps there's a way to create also
a set of per-project permissions to allow to either set this globally
or per project.

Thanks,
Mauro

Re: Linking Patchwork with Sashiko?

[Mauro Carvalho Chehab]

On Thu, 4 Jun 2026 08:52:01 +0200
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> wrote:

> On Wed, 3 Jun 2026 09:50:06 +1000
> Matthieu Baerts <matttbe@kernel.org> wrote:
> 
> > Hi Mauro, Derek, Roman,
> > 
> > On 03/06/2026 06:39, Mauro Carvalho Chehab wrote:  
> > > On Tue, 02 Jun 2026 20:13:15 +0000
> > > Roman Gushchin <roman.gushchin@linux.dev> wrote:    
> > >> Derek Barbosa <debarbos@redhat.com> writes:    
> > >>> On Sat, May 30, 2026 at 08:53:51PM +0200, Mauro Carvalho Chehab wrote:      
> > 
> > (...)
> >   
> > >>> - pw_tools is a workaround solution to get/set status on patchwork via bot-mail
> > >>>   parsing. pw tokens also have broad permission scope.
> > >>>
> > >>> which that leaves us with two "methods" of integration:
> > >>>
> > >>> 1. The Sashiko daemon calls the pw_tools script directly to update the status.
> > >>> 2. Sashiko sends a single-per-patch-email with parseable "status" to a mailing
> > >>> list, where some running daemon will pickup the mail.      
> > >>
> > >> This feels a bit hacky.    
> > > 
> > > The alternative that would be acceptable, at least on media, is if 
> > > one would add support on patchwork to have a separate permission just
> > > for checks update.    
> > 
> > Indeed. It looks like there is an old feature request about that:
> > 
> >   https://github.com/getpatchwork/patchwork/issues/14
> > 
> > Linked to Mauro's email from Dec 2015 :)  
> 
> If it is OK to have a global CI permission, I think this patch
> would do the trick (currently untested):

Added both global and per-project permissions to add CI checks:

	https://github.com/getpatchwork/patchwork/pull/653

Tested on a docker container created on the top of current
upstream, with the database imported from linuxtv.org and
migrated to the new permissions model.

Regards,
Mauro

Thanks,
Mauro

Re: Linking Patchwork with Sashiko?

[Derek Barbosa]

On Sun, Jun 07, 2026 at 07:56:56PM +0200, Mauro Carvalho Chehab wrote:
> Added both global and per-project permissions to add CI checks:
> 
> 	https://github.com/getpatchwork/patchwork/pull/653
> 
> Tested on a docker container created on the top of current
> upstream, with the database imported from linuxtv.org and
> migrated to the new permissions model.

Hi Mauro,

Patchwork integration has been cleaned up and the original issues filed against
the Sashiko project have been resolved.

Any progress on your work for the permissions modifications (or enabling it for
media)?

Cheers,

-- 
Derek <debarbos@redhat.com>

Re: Linking Patchwork with Sashiko?

[Mauro Carvalho Chehab]

Hi Derek,

On Tue, 30 Jun 2026 16:32:30 -0400
Derek Barbosa <debarbos@redhat.com> wrote:

> On Sun, Jun 07, 2026 at 07:56:56PM +0200, Mauro Carvalho Chehab wrote:
> > Added both global and per-project permissions to add CI checks:
> > 
> > 	https://github.com/getpatchwork/patchwork/pull/653
> > 
> > Tested on a docker container created on the top of current
> > upstream, with the database imported from linuxtv.org and
> > migrated to the new permissions model.  
> 
> Hi Mauro,
> 
> Patchwork integration has been cleaned up and the original issues filed against
> the Sashiko project have been resolved.
> 
> Any progress on your work for the permissions modifications (or enabling it for
> media)?

I'd like to have the permission modification changes applied at
Patchwork upstream before applying it to linux-media instance, as
this will require a DB change, which can make it harder in the future
to update linux-media patchwork instance, especially if upstream ends
with some changes over my proposed patch.

So, while patchwork doesn't have a separated permission for checks
addition, we'll keep using my tool to update bots feedback from
e-mails. To prevent too much noise at linux-media, we have now a

	media-ci@linuxtv.org

mailing list that is meant to receive all bots feedback. The
e-mail parser is listening to it as well.

Thanks,
Mauro

Re: Linking Patchwork with Sashiko?

[Mauro Carvalho Chehab]

Hi Derek/Roman,

On Fri, 10 Jul 2026 07:45:28 +0200
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> wrote:

> Hi Derek,
> 
> On Tue, 30 Jun 2026 16:32:30 -0400
> Derek Barbosa <debarbos@redhat.com> wrote:
> 
> > On Sun, Jun 07, 2026 at 07:56:56PM +0200, Mauro Carvalho Chehab wrote:  
> > > Added both global and per-project permissions to add CI checks:
> > > 
> > > 	https://github.com/getpatchwork/patchwork/pull/653
> > > 
> > > Tested on a docker container created on the top of current
> > > upstream, with the database imported from linuxtv.org and
> > > migrated to the new permissions model.    
> > 
> > Hi Mauro,
> > 
> > Patchwork integration has been cleaned up and the original issues filed against
> > the Sashiko project have been resolved.
> > 
> > Any progress on your work for the permissions modifications (or enabling it for
> > media)?  
> 
> I'd like to have the permission modification changes applied at
> Patchwork upstream before applying it to linux-media instance, as
> this will require a DB change, which can make it harder in the future
> to update linux-media patchwork instance, especially if upstream ends
> with some changes over my proposed patch.
> 
> So, while patchwork doesn't have a separated permission for checks
> addition, we'll keep using my tool to update bots feedback from
> e-mails. To prevent too much noise at linux-media, we have now a
> 
> 	media-ci@linuxtv.org
> 
> mailing list that is meant to receive all bots feedback. The
> e-mail parser is listening to it as well.

Btw, we did an inquire among the participants of the latest media
summit, where we discussed Sashiko.

There is a consensus of receiving Sashiko feedback at 
media-ci@linuxtv.org, where people can opt-in/opt-out.

With regards to c/c authors, there was a proposal to add a custom 
disclaimer's notice on each patch. Also, several people manifested
that it should be possible for authors to opt-out receiving Sashiko's
e-mails.

So, at least with the current way, we were unable to reach a
consensus (or a large majority) about c/c the author.

So, what it is a consensus is to receive Sashiko's email via
media-ci@linuxtv.org, evaluating its feedback results for a couple 
of kernel releases. IMO, it is better to receive there also e-mails
if Sashiko didn't find any issue.

One interesting feedback was related to a review from i.MX DTS and DMAEngine 
I3C patch series.

I guess it could be the start of a custom linux-media prompt.

The original suggestion is:

	"I suggested add some actionable advice.  The below action when I handle
	i.MX DTS and DMAEngine\I3C sashakio review feedback.  

	- "Pre existing issue" \ "not introduce by this patch", can omit this feedback,
	But encourage fix at following patch
	- "UAF" or lock issue,  most like is true issue, strongly suggest fix it. Maintainer
	Most likely double check this type issue.
	- Small issue like "typo" or "indention",  please fix before maintainer involve
	Review. 
	- other identify severity is HIGH issue, suggest reply sashiko email and provide
	Your judgement when close to land."

There was also a discussion about a magic number inside a loop:

	for (unsigned int i = 0; i < 56; i++) {

(on such loop, "i" was used to access an array)

Sashiko didn't pick this one on one of his reviews.


I guess we can start with a custom RAC prompt to make Sashiko
classify its output according with a criteria similar to the
above.

E.g. maybe linux-media may start with a custom prompt similar to this
(as part of a more complete RAC):

	### Classification categories and actions

	1. **Pre‑existing issues** - a bug or flaw that already exists in the current code and is *not introduced by this patch*.  
	   - **Action**: Place at the end, under "Further suggestions". Note that the issue could be addressed on a separate patch  
	   - Mark as: `classification: PRE_EXISTING`, `action: DEFER_FOLLOWUP`.

	2. **UAF / Lock issues** - use‑after‑free, race condition, missing lock, double unlock, deadlock, incorrect refcounting, etc.  
	   - **Action**: This is almost certainly a true bug. Encourage the author to check or consult an expert if in doubt.
	   - Mark as: `classification: CRITICAL_LOCKING_UAF`, `action: MUST_FIX`.

	3. **Small issues** - typo, indentation, coding‑style, whitespace, missing blank line, comment grammar, overly long line, etc.  
	   - **Action**: These should be corrected before the maintainer becomes involved in the review.  
	   - Mark as: `classification: STYLE_TYPO`, `action: FIX_BEFORE_MAINTAINER`.

	4. **Magic numbers** - when a numeric literal (like `56`, `128`) is used without a defined constant or obvious connection to an array size. 
	   - **Action**: These should be corrected before the maintainer becomes involved in the review.  
	   - Mark as: `classification: MAGIC_NUMBER`, `action: FIX_BEFORE_MAINTAINER`.

	5. **Other HIGH severity issues** – any problem that is clearly a functional bug (logic error, NULL deref, buffer overflow, API misuse, incorrect error handling, memory leak, etc.) that does not fall into category 2.  
	   - **Action**: the authors should provide their own judgment on the issue (e.g., explain why it is a false positive, or confirm the fix).  
	   - Mark as: `classification: HIGH_OTHER`, `action: REPLY_WITH_JUDGMENT_NEAR_LANDING`.

	6. **Low severity / Informational** – anything that does not fit the above (e.g., suggestion, minor question, potential improvement that is not a bug).  
	   - **Action**: Optional; can be addressed at author’s discretion.  
	   - Mark as: `classification: LOW_INFO`, `action: OPTIONAL`.

Please notice that we're not a prompt experts - nor, afaikt, any media
developer tested running Sashiko locally themselves - so you probably can
come up with a better custom prompt than us.

Thanks,
Mauro

Re: Linking Patchwork with Sashiko?

[Roman Gushchin]

Mauro Carvalho Chehab <mchehab+huawei@kernel.org> writes:

> Hi Derek/Roman,
>
> On Fri, 10 Jul 2026 07:45:28 +0200
> Mauro Carvalho Chehab <mchehab+huawei@kernel.org> wrote:
>
>> Hi Derek,
>> 
>> On Tue, 30 Jun 2026 16:32:30 -0400
>> Derek Barbosa <debarbos@redhat.com> wrote:
>> 
>> > On Sun, Jun 07, 2026 at 07:56:56PM +0200, Mauro Carvalho Chehab wrote:  
>> > > Added both global and per-project permissions to add CI checks:
>> > > 
>> > > 	https://github.com/getpatchwork/patchwork/pull/653
>> > > 
>> > > Tested on a docker container created on the top of current
>> > > upstream, with the database imported from linuxtv.org and
>> > > migrated to the new permissions model.    
>> > 
>> > Hi Mauro,
>> > 
>> > Patchwork integration has been cleaned up and the original issues filed against
>> > the Sashiko project have been resolved.
>> > 
>> > Any progress on your work for the permissions modifications (or enabling it for
>> > media)?  
>> 
>> I'd like to have the permission modification changes applied at
>> Patchwork upstream before applying it to linux-media instance, as
>> this will require a DB change, which can make it harder in the future
>> to update linux-media patchwork instance, especially if upstream ends
>> with some changes over my proposed patch.
>> 
>> So, while patchwork doesn't have a separated permission for checks
>> addition, we'll keep using my tool to update bots feedback from
>> e-mails. To prevent too much noise at linux-media, we have now a
>> 
>> 	media-ci@linuxtv.org
>> 
>> mailing list that is meant to receive all bots feedback. The
>> e-mail parser is listening to it as well.
>
> Btw, we did an inquire among the participants of the latest media
> summit, where we discussed Sashiko.
>
> There is a consensus of receiving Sashiko feedback at 
> media-ci@linuxtv.org, where people can opt-in/opt-out.
>
> With regards to c/c authors, there was a proposal to add a custom 
> disclaimer's notice on each patch. Also, several people manifested
> that it should be possible for authors to opt-out receiving Sashiko's
> e-mails.

Sorry, I'm not sure how it's supposed to work (opt-in/opt-out).
My take is that Sashiko (the sashiko.dev instance, not private/corp
instances) is a tool for maintainers, not individual authors.
I rely on corresponding maintainers decision on whether emails are
sent to the corresponding mailing list. Individuals can set their
spam filters up if they don't want to get these emails, I can't control
it. Providing individual authors an option "I don't want my patches
to be reviewed" sound strange to me. It's like "I don't want my patches
to be tested by unit tests".

> So, at least with the current way, we were unable to reach a
> consensus (or a large majority) about c/c the author.

You can start with cc mailing list only or a set of enthusiasts.

> So, what it is a consensus is to receive Sashiko's email via
> media-ci@linuxtv.org, evaluating its feedback results for a couple 
> of kernel releases. IMO, it is better to receive there also e-mails
> if Sashiko didn't find any issue.

There is such an option, we can enable it.
Should I move on and enable reviews to be sent to media-ci@linuxtv.org?

> One interesting feedback was related to a review from i.MX DTS and DMAEngine 
> I3C patch series.
>
> I guess it could be the start of a custom linux-media prompt.
>
> The original suggestion is:
>
> 	"I suggested add some actionable advice.  The below action when I handle
> 	i.MX DTS and DMAEngine\I3C sashakio review feedback.  
>
> 	- "Pre existing issue" \ "not introduce by this patch", can omit this feedback,
> 	But encourage fix at following patch
> 	- "UAF" or lock issue,  most like is true issue, strongly suggest fix it. Maintainer
> 	Most likely double check this type issue.
> 	- Small issue like "typo" or "indention",  please fix before maintainer involve
> 	Review. 
> 	- other identify severity is HIGH issue, suggest reply sashiko email and provide
> 	Your judgement when close to land."

Re disclaimers and addition instructions in emails - we can discuss it,
but my personal preference would be to keep the minimal - after getting
like 10 emails from Sashiko it will feel like legal disclaimers written
in small font - something that nobody reads and it just wastes the
screen space. So maybe we can put these subsystem-specific rules
somewhere and just provide a link in every email? Just an idea.

> There was also a discussion about a magic number inside a loop:
>
> 	for (unsigned int i = 0; i < 56; i++) {
>
> (on such loop, "i" was used to access an array)
>
> Sashiko didn't pick this one on one of his reviews.

This is a good candidate for some generic prompt, not subsystem-specific.

>
>
> I guess we can start with a custom RAC prompt to make Sashiko
> classify its output according with a criteria similar to the
> above.
>
> E.g. maybe linux-media may start with a custom prompt similar to this
> (as part of a more complete RAC):
>
> 	### Classification categories and actions
>
> 	1. **Pre‑existing issues** - a bug or flaw that already exists in the current code and is *not introduced by this patch*.  
> 	   - **Action**: Place at the end, under "Further suggestions". Note that the issue could be addressed on a separate patch  
> 	   - Mark as: `classification: PRE_EXISTING`, `action: DEFER_FOLLOWUP`.
>
> 	2. **UAF / Lock issues** - use‑after‑free, race condition, missing lock, double unlock, deadlock, incorrect refcounting, etc.  
> 	   - **Action**: This is almost certainly a true bug. Encourage the author to check or consult an expert if in doubt.
> 	   - Mark as: `classification: CRITICAL_LOCKING_UAF`, `action: MUST_FIX`.
>
> 	3. **Small issues** - typo, indentation, coding‑style, whitespace, missing blank line, comment grammar, overly long line, etc.  
> 	   - **Action**: These should be corrected before the maintainer becomes involved in the review.  
> 	   - Mark as: `classification: STYLE_TYPO`, `action: FIX_BEFORE_MAINTAINER`.
>
> 	4. **Magic numbers** - when a numeric literal (like `56`, `128`) is used without a defined constant or obvious connection to an array size. 
> 	   - **Action**: These should be corrected before the maintainer becomes involved in the review.  
> 	   - Mark as: `classification: MAGIC_NUMBER`, `action: FIX_BEFORE_MAINTAINER`.
>
> 	5. **Other HIGH severity issues** – any problem that is clearly a functional bug (logic error, NULL deref, buffer overflow, API misuse, incorrect error handling, memory leak, etc.) that does not fall into category 2.  
> 	   - **Action**: the authors should provide their own judgment on the issue (e.g., explain why it is a false positive, or confirm the fix).  
> 	   - Mark as: `classification: HIGH_OTHER`, `action: REPLY_WITH_JUDGMENT_NEAR_LANDING`.
>
> 	6. **Low severity / Informational** – anything that does not fit the above (e.g., suggestion, minor question, potential improvement that is not a bug).  
> 	   - **Action**: Optional; can be addressed at author’s discretion.  
> 	   - Mark as: `classification: LOW_INFO`, `action: OPTIONAL`.
>
> Please notice that we're not a prompt experts - nor, afaikt, any media
> developer tested running Sashiko locally themselves - so you probably can
> come up with a better custom prompt than us.

I'll take a look, thanks!

Thank you!

Re: Linking Patchwork with Sashiko?

[Mauro Carvalho Chehab]

On Fri, 10 Jul 2026 18:01:38 -0700
Roman Gushchin <roman.gushchin@linux.dev> wrote:

> Mauro Carvalho Chehab <mchehab+huawei@kernel.org> writes:
> 
> > Hi Derek/Roman,
> >
> > On Fri, 10 Jul 2026 07:45:28 +0200
> > Mauro Carvalho Chehab <mchehab+huawei@kernel.org> wrote:
> >  
> >> Hi Derek,
> >> 
> >> On Tue, 30 Jun 2026 16:32:30 -0400
> >> Derek Barbosa <debarbos@redhat.com> wrote:
> >>   
> >> > On Sun, Jun 07, 2026 at 07:56:56PM +0200, Mauro Carvalho Chehab wrote:    
> >> > > Added both global and per-project permissions to add CI checks:
> >> > > 
> >> > > 	https://github.com/getpatchwork/patchwork/pull/653
> >> > > 
> >> > > Tested on a docker container created on the top of current
> >> > > upstream, with the database imported from linuxtv.org and
> >> > > migrated to the new permissions model.      
> >> > 
> >> > Hi Mauro,
> >> > 
> >> > Patchwork integration has been cleaned up and the original issues filed against
> >> > the Sashiko project have been resolved.
> >> > 
> >> > Any progress on your work for the permissions modifications (or enabling it for
> >> > media)?    
> >> 
> >> I'd like to have the permission modification changes applied at
> >> Patchwork upstream before applying it to linux-media instance, as
> >> this will require a DB change, which can make it harder in the future
> >> to update linux-media patchwork instance, especially if upstream ends
> >> with some changes over my proposed patch.
> >> 
> >> So, while patchwork doesn't have a separated permission for checks
> >> addition, we'll keep using my tool to update bots feedback from
> >> e-mails. To prevent too much noise at linux-media, we have now a
> >> 
> >> 	media-ci@linuxtv.org
> >> 
> >> mailing list that is meant to receive all bots feedback. The
> >> e-mail parser is listening to it as well.  
> >
> > Btw, we did an inquire among the participants of the latest media
> > summit, where we discussed Sashiko.
> >
> > There is a consensus of receiving Sashiko feedback at 
> > media-ci@linuxtv.org, where people can opt-in/opt-out.
> >
> > With regards to c/c authors, there was a proposal to add a custom 
> > disclaimer's notice on each patch. Also, several people manifested
> > that it should be possible for authors to opt-out receiving Sashiko's
> > e-mails.  
> 
> Sorry, I'm not sure how it's supposed to work (opt-in/opt-out).
> My take is that Sashiko (the sashiko.dev instance, not private/corp
> instances) is a tool for maintainers, not individual authors.

IMO, sashiko.dev could have an e-mail interface to enable/disable
delivers to authors on a similar way to what mailman does. For instance, 
if an author replies to be "unsubscribed" (or access some web interface),
a confirm e-mail with an unique token ID would be sent to his e-mail.
After replying to it, the author would be blacklisted on e-mail
delivery.

This is for authors only.

> I rely on corresponding maintainers decision on whether emails are
> sent to the corresponding mailing list. 

Mailing lists is a different case: the decision should be taken by
maintainers. Only maintainers can change that.

> Individuals can set their
> spam filters up if they don't want to get these emails, I can't control
> it. Providing individual authors an option "I don't want my patches
> to be reviewed" sound strange to me. It's like "I don't want my patches
> to be tested by unit tests".

I agree with you, and, on my head, not sending e-mails to the author
is a clear violation to one of the most basic net etiquette rule on
mailing lists: any replies to posts there should reach the author.

Unfortunately, some people have too strong opinions against LLM,
and don't even want to setup filters related to it.

> > So, at least with the current way, we were unable to reach a
> > consensus (or a large majority) about c/c the author.  
> 
> You can start with cc mailing list only or a set of enthusiasts.

Yes.

> 
> > So, what it is a consensus is to receive Sashiko's email via
> > media-ci@linuxtv.org, evaluating its feedback results for a couple 
> > of kernel releases. IMO, it is better to receive there also e-mails
> > if Sashiko didn't find any issue.  
> 
> There is such an option, we can enable it.
> Should I move on and enable reviews to be sent to media-ci@linuxtv.org?

Yes, please. This way, media developers interested on receiving Sashiko
reviews may get access to it. It will also feed media patchwork instance
at:
	https://patchwork.linuxtv.org/project/linux-media/list/

> > One interesting feedback was related to a review from i.MX DTS and DMAEngine 
> > I3C patch series.
> >
> > I guess it could be the start of a custom linux-media prompt.
> >
> > The original suggestion is:
> >
> > 	"I suggested add some actionable advice.  The below action when I handle
> > 	i.MX DTS and DMAEngine\I3C sashakio review feedback.  
> >
> > 	- "Pre existing issue" \ "not introduce by this patch", can omit this feedback,
> > 	But encourage fix at following patch
> > 	- "UAF" or lock issue,  most like is true issue, strongly suggest fix it. Maintainer
> > 	Most likely double check this type issue.
> > 	- Small issue like "typo" or "indention",  please fix before maintainer involve
> > 	Review. 
> > 	- other identify severity is HIGH issue, suggest reply sashiko email and provide
> > 	Your judgement when close to land."  
> 
> Re disclaimers and addition instructions in emails - we can discuss it,
> but my personal preference would be to keep the minimal - after getting
> like 10 emails from Sashiko it will feel like legal disclaimers written
> in small font - something that nobody reads and it just wastes the
> screen space. So maybe we can put these subsystem-specific rules
> somewhere and just provide a link in every email? Just an idea.

Disclaimers on e-mails are, IMO, important to new contributors. You're
right that experienced developers will ignore it, but having a simple
disclaimer's notice informing that bot reviews may make mistakes and
that, in case of doubt one must consult an experienced developer is a
good thing. We had some discussions on media to have a prompt similar
to this:

    This is an LLM-generated review that can be prone to hallucinations.
    It is fine to ignore this review.
    When in doubt about some of the findings, please consult
    an experienced developer.

I even tried wrote some code adding it at:
	https://github.com/mchehab/sashiko/commit/5e3ec00772e9bc7a9e7d90993674d822a7bc200f
	https://github.com/mchehab/sashiko/commit/eff8622fe2828efc56cd38037cb837d28ebd3914

they are on this branch:
	https://github.com/mchehab/sashiko/tree/linux-media

but this was before the discussions with regards to c/c authors.
Also, please notice that I never wrote Rust code before, so the
rust patch is likely not perfect: it is compile-tested only.

> 
> > There was also a discussion about a magic number inside a loop:
> >
> > 	for (unsigned int i = 0; i < 56; i++) {
> >
> > (on such loop, "i" was used to access an array)
> >
> > Sashiko didn't pick this one on one of his reviews.  
> 
> This is a good candidate for some generic prompt, not subsystem-specific.

Agreed.

> 
> >
> >
> > I guess we can start with a custom RAC prompt to make Sashiko
> > classify its output according with a criteria similar to the
> > above.
> >
> > E.g. maybe linux-media may start with a custom prompt similar to this
> > (as part of a more complete RAC):
> >
> > 	### Classification categories and actions
> >
> > 	1. **Pre‑existing issues** - a bug or flaw that already exists in the current code and is *not introduced by this patch*.  
> > 	   - **Action**: Place at the end, under "Further suggestions". Note that the issue could be addressed on a separate patch  
> > 	   - Mark as: `classification: PRE_EXISTING`, `action: DEFER_FOLLOWUP`.
> >
> > 	2. **UAF / Lock issues** - use‑after‑free, race condition, missing lock, double unlock, deadlock, incorrect refcounting, etc.  
> > 	   - **Action**: This is almost certainly a true bug. Encourage the author to check or consult an expert if in doubt.
> > 	   - Mark as: `classification: CRITICAL_LOCKING_UAF`, `action: MUST_FIX`.
> >
> > 	3. **Small issues** - typo, indentation, coding‑style, whitespace, missing blank line, comment grammar, overly long line, etc.  
> > 	   - **Action**: These should be corrected before the maintainer becomes involved in the review.  
> > 	   - Mark as: `classification: STYLE_TYPO`, `action: FIX_BEFORE_MAINTAINER`.
> >
> > 	4. **Magic numbers** - when a numeric literal (like `56`, `128`) is used without a defined constant or obvious connection to an array size. 
> > 	   - **Action**: These should be corrected before the maintainer becomes involved in the review.  
> > 	   - Mark as: `classification: MAGIC_NUMBER`, `action: FIX_BEFORE_MAINTAINER`.
> >
> > 	5. **Other HIGH severity issues** – any problem that is clearly a functional bug (logic error, NULL deref, buffer overflow, API misuse, incorrect error handling, memory leak, etc.) that does not fall into category 2.  
> > 	   - **Action**: the authors should provide their own judgment on the issue (e.g., explain why it is a false positive, or confirm the fix).  
> > 	   - Mark as: `classification: HIGH_OTHER`, `action: REPLY_WITH_JUDGMENT_NEAR_LANDING`.
> >
> > 	6. **Low severity / Informational** – anything that does not fit the above (e.g., suggestion, minor question, potential improvement that is not a bug).  
> > 	   - **Action**: Optional; can be addressed at author’s discretion.  
> > 	   - Mark as: `classification: LOW_INFO`, `action: OPTIONAL`.
> >
> > Please notice that we're not a prompt experts - nor, afaikt, any media
> > developer tested running Sashiko locally themselves - so you probably can
> > come up with a better custom prompt than us.  
> 
> I'll take a look, thanks!

Thank you!

Btw, it occurred to me that we could also pick some things from Media Subsystem 
profile as well, from its addendum:
	https://docs.kernel.org/driver-api/media/maintainer-entry-profile.html#submit-checklist-addendum

like adding a feedback that new drivers need to pass at the compliance
tools if the patch series is adding new drivers.

Thanks,
Mauro

Re: Linking Patchwork with Sashiko?

[Laurent Pinchart]

On Mon, Jul 13, 2026 at 09:55:38AM +0200, Mauro Carvalho Chehab wrote:
> On Fri, 10 Jul 2026 18:01:38 -0700 Roman Gushchin wrote:
> > Mauro Carvalho Chehab writes:
> > > On Fri, 10 Jul 2026 07:45:28 +0200 Mauro Carvalho Chehab wrote:
> > >> On Tue, 30 Jun 2026 16:32:30 -0400 Derek Barbosa wrote:
> > >> > On Sun, Jun 07, 2026 at 07:56:56PM +0200, Mauro Carvalho Chehab wrote:    
> > >> > > Added both global and per-project permissions to add CI checks:
> > >> > > 
> > >> > > 	https://github.com/getpatchwork/patchwork/pull/653
> > >> > > 
> > >> > > Tested on a docker container created on the top of current
> > >> > > upstream, with the database imported from linuxtv.org and
> > >> > > migrated to the new permissions model.      
> > >> > 
> > >> > Hi Mauro,
> > >> > 
> > >> > Patchwork integration has been cleaned up and the original issues filed against
> > >> > the Sashiko project have been resolved.
> > >> > 
> > >> > Any progress on your work for the permissions modifications (or enabling it for
> > >> > media)?    
> > >> 
> > >> I'd like to have the permission modification changes applied at
> > >> Patchwork upstream before applying it to linux-media instance, as
> > >> this will require a DB change, which can make it harder in the future
> > >> to update linux-media patchwork instance, especially if upstream ends
> > >> with some changes over my proposed patch.
> > >> 
> > >> So, while patchwork doesn't have a separated permission for checks
> > >> addition, we'll keep using my tool to update bots feedback from
> > >> e-mails. To prevent too much noise at linux-media, we have now a
> > >> 
> > >> 	media-ci@linuxtv.org
> > >> 
> > >> mailing list that is meant to receive all bots feedback. The
> > >> e-mail parser is listening to it as well.  
> > >
> > > Btw, we did an inquire among the participants of the latest media
> > > summit, where we discussed Sashiko.
> > >
> > > There is a consensus of receiving Sashiko feedback at 
> > > media-ci@linuxtv.org, where people can opt-in/opt-out.
> > >
> > > With regards to c/c authors, there was a proposal to add a custom 
> > > disclaimer's notice on each patch. Also, several people manifested
> > > that it should be possible for authors to opt-out receiving Sashiko's
> > > e-mails.  
> > 
> > Sorry, I'm not sure how it's supposed to work (opt-in/opt-out).
> > My take is that Sashiko (the sashiko.dev instance, not private/corp
> > instances) is a tool for maintainers, not individual authors.
> 
> IMO, sashiko.dev could have an e-mail interface to enable/disable
> delivers to authors on a similar way to what mailman does. For instance, 
> if an author replies to be "unsubscribed" (or access some web interface),
> a confirm e-mail with an unique token ID would be sent to his e-mail.
> After replying to it, the author would be blacklisted on e-mail
> delivery.
> 
> This is for authors only.
> 
> > I rely on corresponding maintainers decision on whether emails are
> > sent to the corresponding mailing list. 
> 
> Mailing lists is a different case: the decision should be taken by
> maintainers. Only maintainers can change that.
> 
> > Individuals can set their
> > spam filters up if they don't want to get these emails, I can't control
> > it. Providing individual authors an option "I don't want my patches
> > to be reviewed" sound strange to me. It's like "I don't want my patches
> > to be tested by unit tests".
> 
> I agree with you, and, on my head, not sending e-mails to the author
> is a clear violation to one of the most basic net etiquette rule on
> mailing lists: any replies to posts there should reach the author.

I don't know where that one comes from.

What happened to this other "most basic rule" that subscription to
services that deliver e-mails should be opt-in ?

> Unfortunately, some people have too strong opinions against LLM,
> and don't even want to setup filters related to it.
> 
> > > So, at least with the current way, we were unable to reach a
> > > consensus (or a large majority) about c/c the author.  
> > 
> > You can start with cc mailing list only or a set of enthusiasts.
> 
> Yes.
> 
> > > So, what it is a consensus is to receive Sashiko's email via
> > > media-ci@linuxtv.org, evaluating its feedback results for a couple 
> > > of kernel releases. IMO, it is better to receive there also e-mails
> > > if Sashiko didn't find any issue.  
> > 
> > There is such an option, we can enable it.
> > Should I move on and enable reviews to be sent to media-ci@linuxtv.org?
> 
> Yes, please. This way, media developers interested on receiving Sashiko
> reviews may get access to it. It will also feed media patchwork instance
> at:
> 	https://patchwork.linuxtv.org/project/linux-media/list/
> 
> > > One interesting feedback was related to a review from i.MX DTS and DMAEngine 
> > > I3C patch series.
> > >
> > > I guess it could be the start of a custom linux-media prompt.
> > >
> > > The original suggestion is:
> > >
> > > 	"I suggested add some actionable advice.  The below action when I handle
> > > 	i.MX DTS and DMAEngine\I3C sashakio review feedback.  
> > >
> > > 	- "Pre existing issue" \ "not introduce by this patch", can omit this feedback,
> > > 	But encourage fix at following patch
> > > 	- "UAF" or lock issue,  most like is true issue, strongly suggest fix it. Maintainer
> > > 	Most likely double check this type issue.
> > > 	- Small issue like "typo" or "indention",  please fix before maintainer involve
> > > 	Review. 
> > > 	- other identify severity is HIGH issue, suggest reply sashiko email and provide
> > > 	Your judgement when close to land."  
> > 
> > Re disclaimers and addition instructions in emails - we can discuss it,
> > but my personal preference would be to keep the minimal - after getting
> > like 10 emails from Sashiko it will feel like legal disclaimers written
> > in small font - something that nobody reads and it just wastes the
> > screen space. So maybe we can put these subsystem-specific rules
> > somewhere and just provide a link in every email? Just an idea.
> 
> Disclaimers on e-mails are, IMO, important to new contributors. You're
> right that experienced developers will ignore it, but having a simple
> disclaimer's notice informing that bot reviews may make mistakes and
> that, in case of doubt one must consult an experienced developer is a
> good thing. We had some discussions on media to have a prompt similar
> to this:
> 
>     This is an LLM-generated review that can be prone to hallucinations.
>     It is fine to ignore this review.
>     When in doubt about some of the findings, please consult
>     an experienced developer.
> 
> I even tried wrote some code adding it at:
> 	https://github.com/mchehab/sashiko/commit/5e3ec00772e9bc7a9e7d90993674d822a7bc200f
> 	https://github.com/mchehab/sashiko/commit/eff8622fe2828efc56cd38037cb837d28ebd3914
> 
> they are on this branch:
> 	https://github.com/mchehab/sashiko/tree/linux-media
> 
> but this was before the discussions with regards to c/c authors.
> Also, please notice that I never wrote Rust code before, so the
> rust patch is likely not perfect: it is compile-tested only.
> 
> > 
> > > There was also a discussion about a magic number inside a loop:
> > >
> > > 	for (unsigned int i = 0; i < 56; i++) {
> > >
> > > (on such loop, "i" was used to access an array)
> > >
> > > Sashiko didn't pick this one on one of his reviews.  
> > 
> > This is a good candidate for some generic prompt, not subsystem-specific.
> 
> Agreed.
> 
> > > I guess we can start with a custom RAC prompt to make Sashiko
> > > classify its output according with a criteria similar to the
> > > above.
> > >
> > > E.g. maybe linux-media may start with a custom prompt similar to this
> > > (as part of a more complete RAC):
> > >
> > > 	### Classification categories and actions
> > >
> > > 	1. **Pre‑existing issues** - a bug or flaw that already exists in the current code and is *not introduced by this patch*.  
> > > 	   - **Action**: Place at the end, under "Further suggestions". Note that the issue could be addressed on a separate patch  
> > > 	   - Mark as: `classification: PRE_EXISTING`, `action: DEFER_FOLLOWUP`.
> > >
> > > 	2. **UAF / Lock issues** - use‑after‑free, race condition, missing lock, double unlock, deadlock, incorrect refcounting, etc.  
> > > 	   - **Action**: This is almost certainly a true bug. Encourage the author to check or consult an expert if in doubt.
> > > 	   - Mark as: `classification: CRITICAL_LOCKING_UAF`, `action: MUST_FIX`.
> > >
> > > 	3. **Small issues** - typo, indentation, coding‑style, whitespace, missing blank line, comment grammar, overly long line, etc.  
> > > 	   - **Action**: These should be corrected before the maintainer becomes involved in the review.  
> > > 	   - Mark as: `classification: STYLE_TYPO`, `action: FIX_BEFORE_MAINTAINER`.
> > >
> > > 	4. **Magic numbers** - when a numeric literal (like `56`, `128`) is used without a defined constant or obvious connection to an array size. 
> > > 	   - **Action**: These should be corrected before the maintainer becomes involved in the review.  
> > > 	   - Mark as: `classification: MAGIC_NUMBER`, `action: FIX_BEFORE_MAINTAINER`.
> > >
> > > 	5. **Other HIGH severity issues** – any problem that is clearly a functional bug (logic error, NULL deref, buffer overflow, API misuse, incorrect error handling, memory leak, etc.) that does not fall into category 2.  
> > > 	   - **Action**: the authors should provide their own judgment on the issue (e.g., explain why it is a false positive, or confirm the fix).  
> > > 	   - Mark as: `classification: HIGH_OTHER`, `action: REPLY_WITH_JUDGMENT_NEAR_LANDING`.
> > >
> > > 	6. **Low severity / Informational** – anything that does not fit the above (e.g., suggestion, minor question, potential improvement that is not a bug).  
> > > 	   - **Action**: Optional; can be addressed at author’s discretion.  
> > > 	   - Mark as: `classification: LOW_INFO`, `action: OPTIONAL`.
> > >
> > > Please notice that we're not a prompt experts - nor, afaikt, any media
> > > developer tested running Sashiko locally themselves - so you probably can
> > > come up with a better custom prompt than us.  
> > 
> > I'll take a look, thanks!
> 
> Thank you!
> 
> Btw, it occurred to me that we could also pick some things from Media Subsystem 
> profile as well, from its addendum:
> 	https://docs.kernel.org/driver-api/media/maintainer-entry-profile.html#submit-checklist-addendum
> 
> like adding a feedback that new drivers need to pass at the compliance
> tools if the patch series is adding new drivers.

-- 
Regards,

Laurent Pinchart

Re: Linking Patchwork with Sashiko?

[Mauro Carvalho Chehab]

On Mon, 13 Jul 2026 12:41:20 +0300
Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote:

> > > Individuals can set their
> > > spam filters up if they don't want to get these emails, I can't control
> > > it. Providing individual authors an option "I don't want my patches
> > > to be reviewed" sound strange to me. It's like "I don't want my patches
> > > to be tested by unit tests".  
> > 
> > I agree with you, and, on my head, not sending e-mails to the author
> > is a clear violation to one of the most basic net etiquette rule on
> > mailing lists: any replies to posts there should reach the author.  
> 
> I don't know where that one comes from.
> 
> What happened to this other "most basic rule" that subscription to
> services that deliver e-mails should be opt-in ?

Replying to an e-mail is not subscribing to a service. It is the
author's right to know if one replies publicly to his e-mails.
Explicitly removing him from the C/C of such replies is a violation
of his rights. 

On other words, it is implicit that, if you post an e-mail, you'll be
expecting actions or answers to it.

Now, if one really doesn't really want to receive e-mails from a
particular sender, a block list solves it. Alternatively, a way to
opt-out is welcomed.

See, this is different than adding someone to a mailing list without
his consent: On such case, people receive e-mails unrelated to their 
preferences. For those, opt-in is the right net etiquette.

Thanks,
Mauro

Re: Linking Patchwork with Sashiko?

[Roman Gushchin]

Mauro Carvalho Chehab <mchehab+huawei@kernel.org> writes:

> On Mon, 13 Jul 2026 12:41:20 +0300
> Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote:
>
>> > > Individuals can set their
>> > > spam filters up if they don't want to get these emails, I can't control
>> > > it. Providing individual authors an option "I don't want my patches
>> > > to be reviewed" sound strange to me. It's like "I don't want my patches
>> > > to be tested by unit tests".  
>> > 
>> > I agree with you, and, on my head, not sending e-mails to the author
>> > is a clear violation to one of the most basic net etiquette rule on
>> > mailing lists: any replies to posts there should reach the author.  
>> 
>> I don't know where that one comes from.
>> 
>> What happened to this other "most basic rule" that subscription to
>> services that deliver e-mails should be opt-in ?
>
> Replying to an e-mail is not subscribing to a service. It is the
> author's right to know if one replies publicly to his e-mails.
> Explicitly removing him from the C/C of such replies is a violation
> of his rights. 
>
> On other words, it is implicit that, if you post an e-mail, you'll be
> expecting actions or answers to it.
>
> Now, if one really doesn't really want to receive e-mails from a
> particular sender, a block list solves it. Alternatively, a way to
> opt-out is welcomed.
>
> See, this is different than adding someone to a mailing list without
> his consent: On such case, people receive e-mails unrelated to their 
> preferences. For those, opt-in is the right net etiquette.

I agree with this.

But also just practically: if someone who opted out from sashiko emails
posts a patch and sashiko finds say a critical issue, do we expect the
maintainer to go and manually check each time whether the author opted
out and forward the review?

Thanks!

Re: Linking Patchwork with Sashiko?

[Laurent Pinchart]

On Tue, Jul 14, 2026 at 10:55:42PM +0000, Roman Gushchin wrote:
> Mauro Carvalho Chehab writes:
> > On Mon, 13 Jul 2026 12:41:20 +0300 Laurent Pinchart wrote:
> >> > > Individuals can set their
> >> > > spam filters up if they don't want to get these emails, I can't control
> >> > > it. Providing individual authors an option "I don't want my patches
> >> > > to be reviewed" sound strange to me. It's like "I don't want my patches
> >> > > to be tested by unit tests".  
> >> > 
> >> > I agree with you, and, on my head, not sending e-mails to the author
> >> > is a clear violation to one of the most basic net etiquette rule on
> >> > mailing lists: any replies to posts there should reach the author.  
> >> 
> >> I don't know where that one comes from.
> >> 
> >> What happened to this other "most basic rule" that subscription to
> >> services that deliver e-mails should be opt-in ?
> >
> > Replying to an e-mail is not subscribing to a service. It is the
> > author's right to know if one replies publicly to his e-mails.
> > Explicitly removing him from the C/C of such replies is a violation
> > of his rights. 
> >
> > On other words, it is implicit that, if you post an e-mail, you'll be
> > expecting actions or answers to it.
> >
> > Now, if one really doesn't really want to receive e-mails from a
> > particular sender, a block list solves it. Alternatively, a way to
> > opt-out is welcomed.
> >
> > See, this is different than adding someone to a mailing list without
> > his consent: On such case, people receive e-mails unrelated to their 
> > preferences. For those, opt-in is the right net etiquette.
> 
> I agree with this.
> 
> But also just practically: if someone who opted out from sashiko emails
> posts a patch and sashiko finds say a critical issue, do we expect the
> maintainer to go and manually check each time whether the author opted
> out and forward the review?

I expect maintainers who want to act on sashiko reviews to triage and
verify them first before bothering authors, yes. I believe we should
follow the first two recommendations of the Software Freedom Conservancy
on using LLM-backed generative AI systems for FOSS contributions ([1]).

[1] https://sfconservancy.org/llm-gen-ai/llm-backed-generative-ai-recommendations.html

-- 
Regards,

Laurent Pinchart

Re: Linking Patchwork with Sashiko?

[Roman Gushchin]

> On Jul 14, 2026, at 5:59 PM, Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote:
> 
> On Tue, Jul 14, 2026 at 10:55:42PM +0000, Roman Gushchin wrote:
>> Mauro Carvalho Chehab writes:
>>>> On Mon, 13 Jul 2026 12:41:20 +0300 Laurent Pinchart wrote:
>>>>>>> Individuals can set their
>>>>>>> spam filters up if they don't want to get these emails, I can't control
>>>>>>> it. Providing individual authors an option "I don't want my patches
>>>>>>> to be reviewed" sound strange to me. It's like "I don't want my patches
>>>>>>> to be tested by unit tests".  
>>>>>> 
>>>>>> I agree with you, and, on my head, not sending e-mails to the author
>>>>>> is a clear violation to one of the most basic net etiquette rule on
>>>>>> mailing lists: any replies to posts there should reach the author.  
>>>>> 
>>>>> I don't know where that one comes from.
>>>>> 
>>>>> What happened to this other "most basic rule" that subscription to
>>>>> services that deliver e-mails should be opt-in ?
>>> 
>>> Replying to an e-mail is not subscribing to a service. It is the
>>> author's right to know if one replies publicly to his e-mails.
>>> Explicitly removing him from the C/C of such replies is a violation
>>> of his rights.
>>> 
>>> On other words, it is implicit that, if you post an e-mail, you'll be
>>> expecting actions or answers to it.
>>> 
>>> Now, if one really doesn't really want to receive e-mails from a
>>> particular sender, a block list solves it. Alternatively, a way to
>>> opt-out is welcomed.
>>> 
>>> See, this is different than adding someone to a mailing list without
>>> his consent: On such case, people receive e-mails unrelated to their
>>> preferences. For those, opt-in is the right net etiquette.
>> 
>> I agree with this.
>> 
>> But also just practically: if someone who opted out from sashiko emails
>> posts a patch and sashiko finds say a critical issue, do we expect the
>> maintainer to go and manually check each time whether the author opted
>> out and forward the review?
> 
> I expect maintainers who want to act on sashiko reviews to triage and
> verify them first before bothering authors, yes. I believe we should
> follow the first two recommendations of the Software Freedom Conservancy
> on using LLM-backed generative AI systems for FOSS contributions ([1]).
> 
> [1] https://sfconservancy.org/llm-gen-ai/llm-backed-generative-ai-recommendations.html

I think it makes the point of sashiko - helping maintainers - unachievable. If the point to not use
LLMs in general, let’s discuss this, not how to make each use case more complex.

It seems like [1]  expresses a very anti-LLM position in general, which I can understand and I agree 
with some of concerns. But I think it’s up to project leaders to decide if Linux in general  takes this 
position and my take so far is that the answer is not.

Thanks

Re: Linking Patchwork with Sashiko?

[Linus Torvalds]

On Tue, 14 Jul 2026 at 19:01, Roman Gushchin <roman.gushchin@linux.dev> wrote:
>
> I think it makes the point of sashiko - helping maintainers - unachievable. If the point to not use
> LLMs in general, let’s discuss this, not how to make each use case more complex.
>
> It seems like [1]  expresses a very anti-LLM position in general

Yes.

And no, that's not the position of the Linux kernel.

I realize that some people really dislike AI, but this is an area
where I'm willing to absolutely put my foot down as the top-level
maintainer.

Linux is not one of those anti-AI projects, and if somebody has issues
with that, they can do the open-source thing and fork it.

Or just walk away.

AI is a tool, just like other tools we use.  And it's clearly a useful one.

It may not have been that "clearly" even just a year ago, but it's no
longer in question today.

There are other questions around AI (like what the economy of it will
actually look like in the end), but "is it useful" is no longer one of
those questions. Anybody who doubts that clearly hasn't actually used
it.

Yes, it can also be a somewhat painful tool, both for maintainer
workloads and just from a "it keeps finding embarrassing bugs"
standpoint.

But the solution is not to put your head in the sand and sing "La La
La, I can't hear you" at the top of your voice like some people seem
to do.

The solution is to make sure those LLM tools _help_ maintainers
instead of just causing them pain. There's no question on that side.

We're not forcing anybody to use it, but I will very loudly ignore
people who try to argue against other people from using it.

And no, AI isn't perfect. But Christ, anybody who points to the
problems at AI had better be looking in the mirror and pointing at
themselves at the same time.

Because it's not like natural intelligence is always all that great either.

The kernel project has been and will continue to be about the technology.

Sure, the social angle of working on open source is important and
often a very motivating part of the project, but in the end that's a
side benefit, not the _point_ of the project.

This is *NOT* some kind of "social warrior" project, never has been,
and never will be.

In the kernel community we do open source because it results in better
technology, not because of religious reasons.

And so we make decisions primarily based on technical merit. Not fear
of new tools.

              Linus

Re: Linking Patchwork with Sashiko?

[Jori Koolstra]

On Tue, Jul 14, 2026 at 08:06:14PM -0700, Linus Torvalds wrote:
> On Tue, 14 Jul 2026 at 19:01, Roman Gushchin <roman.gushchin@linux.dev> wrote:
> >
> > I think it makes the point of sashiko - helping maintainers - unachievable. If the point to not use
> > LLMs in general, let’s discuss this, not how to make each use case more complex.
> >
> > It seems like [1]  expresses a very anti-LLM position in general
> 
> Yes.
> 
> And no, that's not the position of the Linux kernel.
> 
> I realize that some people really dislike AI, but this is an area
> where I'm willing to absolutely put my foot down as the top-level
> maintainer.
> 
> Linux is not one of those anti-AI projects, and if somebody has issues
> with that, they can do the open-source thing and fork it.
> 
> Or just walk away.
> 
> AI is a tool, just like other tools we use.  And it's clearly a useful one.
> 
> It may not have been that "clearly" even just a year ago, but it's no
> longer in question today.
> 
> There are other questions around AI (like what the economy of it will
> actually look like in the end), but "is it useful" is no longer one of
> those questions. Anybody who doubts that clearly hasn't actually used
> it.
> 
> Yes, it can also be a somewhat painful tool, both for maintainer
> workloads and just from a "it keeps finding embarrassing bugs"
> standpoint.
> 
> But the solution is not to put your head in the sand and sing "La La
> La, I can't hear you" at the top of your voice like some people seem
> to do.
> 
> The solution is to make sure those LLM tools _help_ maintainers
> instead of just causing them pain. There's no question on that side.
> 
> We're not forcing anybody to use it, but I will very loudly ignore
> people who try to argue against other people from using it.
> 
> And no, AI isn't perfect. But Christ, anybody who points to the
> problems at AI had better be looking in the mirror and pointing at
> themselves at the same time.
> 
> Because it's not like natural intelligence is always all that great either.
> 
> The kernel project has been and will continue to be about the technology.
> 
> Sure, the social angle of working on open source is important and
> often a very motivating part of the project, but in the end that's a
> side benefit, not the _point_ of the project.
> 
> This is *NOT* some kind of "social warrior" project, never has been,
> and never will be.
> 
> In the kernel community we do open source because it results in better
> technology, not because of religious reasons.
> 
> And so we make decisions primarily based on technical merit. Not fear
> of new tools.

While there is some truly ridiculous anti-LLM brigading in some open
source projects, I feel like saying it is just another tool does not do
justice to some of the harm that is done by that industry. Also,
precisely because of the usefulness of LLMs, I worry about creating an
uneven playing field, where new contributors can't keep up if they can't
afford the needed tools (something that is not as much the case with
compilers.)

These are not arguments that others should not use LLMs, and I find LLMs
to be tremendously useful for reviewing code and understanding context.
But maybe the community could think about these concerns at the same
time, even if its not the main focus. Maybe it is a good side topic for
the Maintainter summit? (or perhaps it is not process-related enough.)

Best,
Jori.

> 
>               Linus

Re: Linking Patchwork with Sashiko?

[Steven Rostedt]

On Wed, 15 Jul 2026 14:21:48 +0200
Jori Koolstra <jkoolstra@xs4all.nl> wrote:

> While there is some truly ridiculous anti-LLM brigading in some open
> source projects, I feel like saying it is just another tool does not do
> justice to some of the harm that is done by that industry. Also,
> precisely because of the usefulness of LLMs, I worry about creating an
> uneven playing field, where new contributors can't keep up if they can't
> afford the needed tools (something that is not as much the case with
> compilers.)
> 
> These are not arguments that others should not use LLMs, and I find LLMs
> to be tremendously useful for reviewing code and understanding context.
> But maybe the community could think about these concerns at the same
> time, even if its not the main focus. Maybe it is a good side topic for
> the Maintainter summit? (or perhaps it is not process-related enough.)

But this is about receiving reviews of patches you send. Really, this is no
different than kernel test robot. At least all critical errors that Sashiko
finds should be sent as a reply, just like anyone else that reviews a patch.

In my experience, the noise has been less than the signal. And the noise is
usually special cases that even a human would likely miss.

-- Steve

Re: Linking Patchwork with Sashiko?

[Nicolas Dufresne]

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

Hey,

Le mercredi 15 juillet 2026 à 14:21 +0200, Jori Koolstra a écrit :
> While there is some truly ridiculous anti-LLM brigading in some open
> source projects, I feel like saying it is just another tool does not do
> justice to some of the harm that is done by that industry. Also,
> precisely because of the usefulness of LLMs, I worry about creating an
> uneven playing field, where new contributors can't keep up if they can't
> afford the needed tools (something that is not as much the case with
> compilers.)

So "fairness" is likely one of the numerous ethical concerns that can drive
activist against LLM (in the sense of people actively avoiding it, boycotting
for the real extreme one, but I want to include mild cases too) in contrast to
luddite, that just don't accept the technology to provide any meaningful result.
I'm personally interested in learning more about each and every ethical
concerns, as this is needed to either fixi or mitigate the social issues this
technology is creating.

On this aspect specifically, Sashiko is provided equally to the Linux community.
This is very unlike coding agent, which capabilities and performance are highly
tailored to your capability to pay. In that sense, fairness is minimally
mitigated. I say mitigated considering someone have to pay for the compute and
because its currently running off proprietary owned models, also require paying
for extra royalties (which is an interesting ethical discussion in itself I
suppose). Smaller projects may not have that level of donation or budget.

Nicolas

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: Linking Patchwork with Sashiko?

[Laurent Pinchart]

On Tue, Jul 14, 2026 at 08:06:14PM -0700, Linus Torvalds wrote:
> On Tue, 14 Jul 2026 at 19:01, Roman Gushchin <roman.gushchin@linux.dev> wrote:
> >
> > I think it makes the point of sashiko - helping maintainers - unachievable. If the point to not use
> > LLMs in general, let’s discuss this, not how to make each use case more complex.
> >
> > It seems like [1]  expresses a very anti-LLM position in general
> 
> Yes.
> 
> And no, that's not the position of the Linux kernel.
> 
> I realize that some people really dislike AI, but this is an area
> where I'm willing to absolutely put my foot down as the top-level
> maintainer.
> 
> Linux is not one of those anti-AI projects, and if somebody has issues
> with that, they can do the open-source thing and fork it.
> 
> Or just walk away.

"My way or the highway" doesn't show a willingness to listen, I'll stop
this reply here.

Maybe those topics are best discussed face to face. I'll be in Prague in
October if you think talking to me has more value than talking to an LLM
;-) (and for clarification, this is really meant as humour to cool down
the discussion, if you find any passive-aggressive interpretation of
this comment please know it's wasn't meant that way).

> AI is a tool, just like other tools we use.  And it's clearly a useful one.
> 
> It may not have been that "clearly" even just a year ago, but it's no
> longer in question today.
> 
> There are other questions around AI (like what the economy of it will
> actually look like in the end), but "is it useful" is no longer one of
> those questions. Anybody who doubts that clearly hasn't actually used
> it.
> 
> Yes, it can also be a somewhat painful tool, both for maintainer
> workloads and just from a "it keeps finding embarrassing bugs"
> standpoint.
> 
> But the solution is not to put your head in the sand and sing "La La
> La, I can't hear you" at the top of your voice like some people seem
> to do.
> 
> The solution is to make sure those LLM tools _help_ maintainers
> instead of just causing them pain. There's no question on that side.
> 
> We're not forcing anybody to use it, but I will very loudly ignore
> people who try to argue against other people from using it.
> 
> And no, AI isn't perfect. But Christ, anybody who points to the
> problems at AI had better be looking in the mirror and pointing at
> themselves at the same time.
> 
> Because it's not like natural intelligence is always all that great either.
> 
> The kernel project has been and will continue to be about the technology.
> 
> Sure, the social angle of working on open source is important and
> often a very motivating part of the project, but in the end that's a
> side benefit, not the _point_ of the project.
> 
> This is *NOT* some kind of "social warrior" project, never has been,
> and never will be.
> 
> In the kernel community we do open source because it results in better
> technology, not because of religious reasons.
> 
> And so we make decisions primarily based on technical merit. Not fear
> of new tools.

-- 
Regards,

Laurent Pinchart

Re: Linking Patchwork with Sashiko?

[Jacopo Mondi]

Hi Roman

On Tue, Jul 14, 2026 at 07:00:54PM -0700, Roman Gushchin wrote:
> > On Jul 14, 2026, at 5:59 PM, Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote:
> >
> > On Tue, Jul 14, 2026 at 10:55:42PM +0000, Roman Gushchin wrote:
> >> Mauro Carvalho Chehab writes:
> >>>> On Mon, 13 Jul 2026 12:41:20 +0300 Laurent Pinchart wrote:
> >>>>>>> Individuals can set their
> >>>>>>> spam filters up if they don't want to get these emails, I can't control
> >>>>>>> it. Providing individual authors an option "I don't want my patches
> >>>>>>> to be reviewed" sound strange to me. It's like "I don't want my patches
> >>>>>>> to be tested by unit tests".
> >>>>>>
> >>>>>> I agree with you, and, on my head, not sending e-mails to the author
> >>>>>> is a clear violation to one of the most basic net etiquette rule on
> >>>>>> mailing lists: any replies to posts there should reach the author.
> >>>>>
> >>>>> I don't know where that one comes from.
> >>>>>
> >>>>> What happened to this other "most basic rule" that subscription to
> >>>>> services that deliver e-mails should be opt-in ?
> >>>
> >>> Replying to an e-mail is not subscribing to a service. It is the
> >>> author's right to know if one replies publicly to his e-mails.
> >>> Explicitly removing him from the C/C of such replies is a violation
> >>> of his rights.
> >>>
> >>> On other words, it is implicit that, if you post an e-mail, you'll be
> >>> expecting actions or answers to it.
> >>>
> >>> Now, if one really doesn't really want to receive e-mails from a
> >>> particular sender, a block list solves it. Alternatively, a way to
> >>> opt-out is welcomed.
> >>>
> >>> See, this is different than adding someone to a mailing list without
> >>> his consent: On such case, people receive e-mails unrelated to their
> >>> preferences. For those, opt-in is the right net etiquette.
> >>
> >> I agree with this.
> >>
> >> But also just practically: if someone who opted out from sashiko emails
> >> posts a patch and sashiko finds say a critical issue, do we expect the
> >> maintainer to go and manually check each time whether the author opted
> >> out and forward the review?
> >
> > I expect maintainers who want to act on sashiko reviews to triage and
> > verify them first before bothering authors, yes. I believe we should
> > follow the first two recommendations of the Software Freedom Conservancy
> > on using LLM-backed generative AI systems for FOSS contributions ([1]).
> >
> > [1] https://sfconservancy.org/llm-gen-ai/llm-backed-generative-ai-recommendations.html
>
> I think it makes the point of sashiko - helping maintainers - unachievable. If the point to not use
> LLMs in general, let’s discuss this, not how to make each use case more complex.
>

Having been in the discussion within the media group, let me try to
re-express here the point I made within that circle already.

The decision to not send Sashiko replies to developers but rather have
them sent to a different mailing list, has been suggested because,
after a brief interim period where Sashiko reviews has been sent to
the main mailing list, it has caused more load for maintainers, not
less.

Far-fetched review comments, very convincing word salads mixed with
valuable findings have often been escalated by authors to maintainers
to have them distil the good from the bad.

This might have merits: analyzing 3 false reports to find a bug is
still worth it, but has so far caused more load for maintainers and
reviewers, not less. Considering reviewers are the most scarce
resource we have, analyzing Sashiko reports has been made an opt-in
feature by sending its review to a dedicated mailing list where
maintainers can (optionally) decide if something's worth acting upon.

This would also give some buffer time to evaluate Sashiko and maybe
reconsider later on.

> It seems like [1]  expresses a very anti-LLM position in general, which I can understand and I agree
> with some of concerns. But I think it’s up to project leaders to decide if Linux in general  takes this
> position and my take so far is that the answer is not.
>

All discussions around AI inevitably ends being about principles and
good vs bad. I'm surprised Linus and Ted had to weight in to re-state
the "we're not against AI!" principle while I would like to discuss
signal-to-noise metrics instead.

Maybe you have number I've not seen yet.

Thanks
   j

> Thanks

Re: Linking Patchwork with Sashiko?

[Mauro Carvalho Chehab]

On Wed, 15 Jul 2026 09:59:57 +0200
Jacopo Mondi <jacopo.mondi@ideasonboard.com> wrote:

> Hi Roman
> 
> On Tue, Jul 14, 2026 at 07:00:54PM -0700, Roman Gushchin wrote:
> > > On Jul 14, 2026, at 5:59 PM, Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote:
> > >
> > > On Tue, Jul 14, 2026 at 10:55:42PM +0000, Roman Gushchin wrote:  
> > >> Mauro Carvalho Chehab writes:  
> > >>>> On Mon, 13 Jul 2026 12:41:20 +0300 Laurent Pinchart wrote:  
> > >>>>>>> Individuals can set their
> > >>>>>>> spam filters up if they don't want to get these emails, I can't control
> > >>>>>>> it. Providing individual authors an option "I don't want my patches
> > >>>>>>> to be reviewed" sound strange to me. It's like "I don't want my patches
> > >>>>>>> to be tested by unit tests".  
> > >>>>>>
> > >>>>>> I agree with you, and, on my head, not sending e-mails to the author
> > >>>>>> is a clear violation to one of the most basic net etiquette rule on
> > >>>>>> mailing lists: any replies to posts there should reach the author.  
> > >>>>>
> > >>>>> I don't know where that one comes from.
> > >>>>>
> > >>>>> What happened to this other "most basic rule" that subscription to
> > >>>>> services that deliver e-mails should be opt-in ?  
> > >>>
> > >>> Replying to an e-mail is not subscribing to a service. It is the
> > >>> author's right to know if one replies publicly to his e-mails.
> > >>> Explicitly removing him from the C/C of such replies is a violation
> > >>> of his rights.
> > >>>
> > >>> On other words, it is implicit that, if you post an e-mail, you'll be
> > >>> expecting actions or answers to it.
> > >>>
> > >>> Now, if one really doesn't really want to receive e-mails from a
> > >>> particular sender, a block list solves it. Alternatively, a way to
> > >>> opt-out is welcomed.
> > >>>
> > >>> See, this is different than adding someone to a mailing list without
> > >>> his consent: On such case, people receive e-mails unrelated to their
> > >>> preferences. For those, opt-in is the right net etiquette.  
> > >>
> > >> I agree with this.
> > >>
> > >> But also just practically: if someone who opted out from sashiko emails
> > >> posts a patch and sashiko finds say a critical issue, do we expect the
> > >> maintainer to go and manually check each time whether the author opted
> > >> out and forward the review?  
> > >
> > > I expect maintainers who want to act on sashiko reviews to triage and
> > > verify them first before bothering authors, yes. I believe we should
> > > follow the first two recommendations of the Software Freedom Conservancy
> > > on using LLM-backed generative AI systems for FOSS contributions ([1]).
> > >
> > > [1] https://sfconservancy.org/llm-gen-ai/llm-backed-generative-ai-recommendations.html  
> >
> > I think it makes the point of sashiko - helping maintainers - unachievable. If the point to not use
> > LLMs in general, let’s discuss this, not how to make each use case more complex.
> >  
> 
> Having been in the discussion within the media group, let me try to
> re-express here the point I made within that circle already.
> 
> The decision to not send Sashiko replies to developers but rather have
> them sent to a different mailing list, has been suggested because,
> after a brief interim period where Sashiko reviews has been sent to
> the main mailing list, it has caused more load for maintainers, not
> less.

At the beginning, any new process generate more load for 
maintainers. The question yet to be answered is how this will
affect our workflow in long term.

> Far-fetched review comments, very convincing word salads mixed with
> valuable findings have often been escalated by authors to maintainers
> to have them distil the good from the bad.
> 
> This might have merits: analyzing 3 false reports to find a bug is
> still worth it, but has so far caused more load for maintainers and
> reviewers, not less. Considering reviewers are the most scarce
> resource we have, analyzing Sashiko reports has been made an opt-in
> feature by sending its review to a dedicated mailing list where
> maintainers can (optionally) decide if something's worth acting upon.

I'm pretty sure we'll need custom prompts to better adjust reviews,
and maybe even adjusting temperature parameters. Media is a complex 
subsystem which deals with a wide range of hardware, several of them
with their own specialized processor units (ISPs) and ASICs.

Any no non-specialized static analyzer tools may report more false
positives on such scenario. Yet, we need authors and maintainers
feedback to adjust such media-specific LLM prompts.

The long term goal should be clear. We expect that, with Sashiko:

- patch quality will be improved after using Sashiko's reviews;
- maintainer's overhead will be reduced, as they won't need to
  restate issues already exposed by CI. They'll only start 
  reviewing once the patches are on a better shape.

If, after using it and customizing its prompts, it turns that the
patch quality decreases or that the maintainers overhead become
too high with very little benefit, then we should review the decision
of using it. 

Not before.

On my personal experience with Sashiko and other LLM-based review
tools, they're very good to check error paths. By using it, we can
avoid receiving extra patches later on to fix things that could
already be solved at the original commit. 

From my experience as maintainer, sometimes it takes years until
someone send us patches fixing error check conditions.

Just take for instance a random fix patch send on May, 22:
	06cb687a5132 ("media: v4l2-fwnode: Fix subdev owner overwritten in v4l2_async_register_subdev_sensor()")

It fixed a patch wrote in 2017:
	Fixes: aef69d54755d ("media: v4l: fwnode: Add a convenience function for registering sensors")

It would be great if, on that time, we had a tool that would be
able to identify such problem and not needing to take ~10 years 
to have it fixed.

> This would also give some buffer time to evaluate Sashiko and maybe
> reconsider later on.
> 
> > It seems like [1]  expresses a very anti-LLM position in general, which I can understand and I agree
> > with some of concerns. But I think it’s up to project leaders to decide if Linux in general  takes this
> > position and my take so far is that the answer is not.
> >  
> 
> All discussions around AI inevitably ends being about principles and
> good vs bad. I'm surprised Linus and Ted had to weight in to re-state
> the "we're not against AI!" principle while I would like to discuss
> signal-to-noise metrics instead.
> 
> Maybe you have number I've not seen yet.
> 
> Thanks
>    j
> 
> > Thanks  



Thanks,
Mauro

Re: Linking Patchwork with Sashiko?

[Theodore Tso]

On Wed, Jul 15, 2026 at 09:59:57AM -0500, Jacopo Mondi wrote:
> Far-fetched review comments, very convincing word salads mixed with
> valuable findings have often been escalated by authors to maintainers
> to have them distil the good from the bad.

That hasn't been my experience with ext4.  As far as signal to noise,
the main issue is one where pre-existing issues are flagged in
multiple patches in the patch series.  However, (a) Romain knows about
this, and a fix is in the works, and (b) it's flagged as a
pre-existing issue --- and we tell newcomers that they are free to
disgard pre-existing issues, but if they do want to fix it, in most
cases do it as a separate patch (or in a separate patch series) and to
avoid folding it into the current patch --- especially if the fix is
non-trivial.

> All discussions around AI inevitably ends being about principles and
> good vs bad. I'm surprised Linus and Ted had to weight in to re-state
> the "we're not against AI!" principle while I would like to discuss
> signal-to-noise metrics instead.

If it makes sense for a subsystem to move reviews to a separate list,
by all means, that should be up to the subsystem maintainers.  There
has been quite a lot of discussion about how we should accomodate
people who object to AI by dumping more work on maintainers, and
that's the part that I object to.

One of the things that really excites me about Shashiko is that it
reduces my workload.  Whereas the false positives from Syxbot and
oss-fuzz have caused me more work, not less, and has had significantly
more noise than Shahiko.  (I've started outright ignoring oss-fuzz
reports as a result, and the "respond within NN days or we will make
our report public" has caused me to respond, "and this will say more
bad things about oss-fuzz than my software"....)

Cheers,

							- Ted

Re: Linking Patchwork with Sashiko?

[Mark Brown]

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

On Tue, Jul 14, 2026 at 07:00:54PM -0700, Roman Gushchin wrote:

> > I expect maintainers who want to act on sashiko reviews to triage and
> > verify them first before bothering authors, yes. I believe we should
> > follow the first two recommendations of the Software Freedom Conservancy
> > on using LLM-backed generative AI systems for FOSS contributions ([1]).

> > [1] https://sfconservancy.org/llm-gen-ai/llm-backed-generative-ai-recommendations.html

> I think it makes the point of sashiko - helping maintainers - unachievable. If the point to not use
> LLMs in general, let’s discuss this, not how to make each use case more complex.

IME flagging areas of the code for consideration is much more reliably
useful than the specific content of what's generated - it helps with
finding areas to focus on, even if the text has all the problems LLM
generated stuff tends to have.  Those pointers can make things a lot
faster when you're reviewing.  

There's a real risk that submitters looking at stuff directly will go
off in the wrong direction if they're not familiar with the area and
trust the output too much, I'm fairly sure I'm seeing the results of
that in a similar fashion to the thing you often see with people sending
patches to mindlessly squash things like uninitialised variable
warnings.

> It seems like [1]  expresses a very anti-LLM position in general, which I can understand and I agree 
> with some of concerns. But I think it’s up to project leaders to decide if Linux in general  takes this 
> position and my take so far is that the answer is not.

Probably worth pointing out that the SFC has come in for a *huge* amount
of criticism for how pro AI people have found the above set of
recommendations to be.

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

Re: Linking Patchwork with Sashiko?

[Laurent Pinchart]

Hi Roman,

On Tue, Jul 14, 2026 at 07:00:54PM -0700, Roman Gushchin wrote:
> On Jul 14, 2026, at 5:59 PM, Laurent Pinchart wrote:
> > On Tue, Jul 14, 2026 at 10:55:42PM +0000, Roman Gushchin wrote:
> >> Mauro Carvalho Chehab writes:
> >>>> On Mon, 13 Jul 2026 12:41:20 +0300 Laurent Pinchart wrote:
> >>>>>>> Individuals can set their
> >>>>>>> spam filters up if they don't want to get these emails, I can't control
> >>>>>>> it. Providing individual authors an option "I don't want my patches
> >>>>>>> to be reviewed" sound strange to me. It's like "I don't want my patches
> >>>>>>> to be tested by unit tests".  
> >>>>>> 
> >>>>>> I agree with you, and, on my head, not sending e-mails to the author
> >>>>>> is a clear violation to one of the most basic net etiquette rule on
> >>>>>> mailing lists: any replies to posts there should reach the author.  
> >>>>> 
> >>>>> I don't know where that one comes from.
> >>>>> 
> >>>>> What happened to this other "most basic rule" that subscription to
> >>>>> services that deliver e-mails should be opt-in ?
> >>> 
> >>> Replying to an e-mail is not subscribing to a service. It is the
> >>> author's right to know if one replies publicly to his e-mails.
> >>> Explicitly removing him from the C/C of such replies is a violation
> >>> of his rights.
> >>> 
> >>> On other words, it is implicit that, if you post an e-mail, you'll be
> >>> expecting actions or answers to it.
> >>> 
> >>> Now, if one really doesn't really want to receive e-mails from a
> >>> particular sender, a block list solves it. Alternatively, a way to
> >>> opt-out is welcomed.
> >>> 
> >>> See, this is different than adding someone to a mailing list without
> >>> his consent: On such case, people receive e-mails unrelated to their
> >>> preferences. For those, opt-in is the right net etiquette.
> >> 
> >> I agree with this.
> >> 
> >> But also just practically: if someone who opted out from sashiko emails
> >> posts a patch and sashiko finds say a critical issue, do we expect the
> >> maintainer to go and manually check each time whether the author opted
> >> out and forward the review?
> > 
> > I expect maintainers who want to act on sashiko reviews to triage and
> > verify them first before bothering authors, yes. I believe we should
> > follow the first two recommendations of the Software Freedom Conservancy
> > on using LLM-backed generative AI systems for FOSS contributions ([1]).
> > 
> > [1] https://sfconservancy.org/llm-gen-ai/llm-backed-generative-ai-recommendations.html
> 
> I think it makes the point of sashiko - helping maintainers - unachievable.

Why do you think so ? As far as I can see, there are many maintainers
and contributors with a strong enthousiasm for generative AI reviews.
Assuming those tools would give a net positive result, isn't that
initial mass sizeable enough to help maintainers ? It could even be
argued that starting with enthousiasts will help convince some of the
sceptics over time.

> If the point to not use LLMs in general, let’s discuss this, not how
> to make each use case more complex.

To be clear, that's not what I'm calling for. I'm asking for
contributors to not be forced to use LLMs. I'm not campaigning for the
kernel to ban their usage.

> It seems like [1]  expresses a very anti-LLM position in general, which I can understand and I agree 
> with some of concerns. But I think it’s up to project leaders to decide if Linux in general  takes this 
> position and my take so far is that the answer is not.

I would be surprised if Linus broadly agreed with [1] :-) I however hope
that we, as a community, have enough shared values to listen to
everybody.

-- 
Regards,

Laurent Pinchart

Re: Linking Patchwork with Sashiko?

[Theodore Tso]

On Wed, Jul 15, 2026 at 03:59:09AM -0500, Laurent Pinchart wrote:
> I believe we should
> follow the first two recommendations of the Software Freedom Conservancy
> on using LLM-backed generative AI systems for FOSS contributions ([1]).
> 
> [1] https://sfconservancy.org/llm-gen-ai/llm-backed-generative-ai-recommendations.html

It's not clear to me that the SFC document is particularly applicable
for the use of LLM's beyond the use case of generating code which is
contributed to FOSS projects.

Things get a lot more complicated when we're considering the use of
LLM's to (a) review code, (b) automate the analysis of a bug report or
stack trace, or (c) automate backporting a patch to LTS kernel.

Consider the first recommendation, "The FOSS community should support,
not just tolerate, those who outright reject LLM-gen-AI systems."  If
someone rejects LLM-gen-AI systems, and the LTS kernel contains
patches which are automated backported, and they object, are we bound
to forswear the use of automated backport technologies?

What if someone reports a bug with a kernel stack trace, and someone
uses an LLM agent to analyze their bug report and find a fix.  What
does it mean to "support somone who outright rejects the use of
LLM-gen-AI systems" in that case?

> I expect maintainers who want to act on sashiko reviews to triage and
> verify them first before bothering authors

As a maintainer, I don't believe I should be forced to rephrase a
Sashiko report just because a patch author "outright rejects" LLM's.
For that matter, I don't believe I'm obliged to accept patches from
someone who forces me to do extra work because they refuse to look at
Sashiko reviews....

How do we balance the needs and time of maintainers with patch
authors?  I don't think it's obvious that we *MUST* bend over
backwards to oblige the needs of all patch authors.

Regards,

						- Ted

Re: Linking Patchwork with Sashiko?

[Mauro Carvalho Chehab]

On Tue, 14 Jul 2026 23:54:43 -0400
"Theodore Tso" <tytso@mit.edu> wrote:

> On Wed, Jul 15, 2026 at 03:59:09AM -0500, Laurent Pinchart wrote:
> > I believe we should
> > follow the first two recommendations of the Software Freedom Conservancy
> > on using LLM-backed generative AI systems for FOSS contributions ([1]).
> > 
> > [1] https://sfconservancy.org/llm-gen-ai/llm-backed-generative-ai-recommendations.html  
> 
> It's not clear to me that the SFC document is particularly applicable
> for the use of LLM's beyond the use case of generating code which is
> contributed to FOSS projects.

Agreed: the document there is about AI-generated code ("Generative AI"),
not about patch review.

> Things get a lot more complicated when we're considering the use of
> LLM's to (a) review code, (b) automate the analysis of a bug report or
> stack trace, or (c) automate backporting a patch to LTS kernel.
> 
> Consider the first recommendation, "The FOSS community should support,
> not just tolerate, those who outright reject LLM-gen-AI systems."  If
> someone rejects LLM-gen-AI systems, and the LTS kernel contains
> patches which are automated backported, and they object, are we bound
> to forswear the use of automated backport technologies?
> 
> What if someone reports a bug with a kernel stack trace, and someone
> uses an LLM agent to analyze their bug report and find a fix.  What
> does it mean to "support somone who outright rejects the use of
> LLM-gen-AI systems" in that case?
> 
> > I expect maintainers who want to act on sashiko reviews to triage and
> > verify them first before bothering authors  
> 
> As a maintainer, I don't believe I should be forced to rephrase a
> Sashiko report just because a patch author "outright rejects" LLM's.
> For that matter, I don't believe I'm obliged to accept patches from
> someone who forces me to do extra work because they refuse to look at
> Sashiko reviews....

As a maintainer, I won't be doing extra work repeating reviews
from LLM (or from any other bot): if the patch is not ok and
there is a report already explaining why, I would simply tag
the patch as "changes needed" on patchwork, letting patchwork bot
to inform the author about the status change without any further
explanation.

As an author, if I submit a patch, I have the right to receive all
reviews, either done by a human or by a bot. This shouldn't be
something that an e-mail policy should be restricting.

I don't care if a bot uses LLM or not: a review is a review: if
it is right, my duty as an author is to fix the code; if the
review turns to be wrong, I have the right to argue against it.

> How do we balance the needs and time of maintainers with patch
> authors?  I don't think it's obvious that we *MUST* bend over
> backwards to oblige the needs of all patch authors.

Finding the right balance is indeed tricky, but Linux should come
first. As Linus mentioned, AI is clearly an useful tool.
Maintainers should use it wisely.

On my view, a good balance would be if Sashiko would have support
in the future to have an opt-out mechanism, replacing the 
`reply_to_author` e-mail policy from:

	https://github.com/sashiko-dev/sashiko/blob/main/sashiko.dev/email_policy.toml

The rationale is that it should not be up to maintainers to decide
that authors will be explicitly excluded from patch reviews.

With an opt-out mechanism, authors can be warned at the opt-out 
interface that maintainers may still to use Sashiko reviews as 
they wish.

-

See, the above is *my view*. Other media developers have different
views. That's why we agreed to start receiving Sashiko reviews at
media-ci@linuxtv.org with reply_to_author disabled for linux-media.

Thanks,
Mauro

Re: Linking Patchwork with Sashiko?

[James Bottomley]

On Wed, 2026-07-15 at 09:13 +0200, Mauro Carvalho Chehab wrote:
> On Tue, 14 Jul 2026 23:54:43 -0400
> "Theodore Tso" <tytso@mit.edu> wrote:
> 
> > On Wed, Jul 15, 2026 at 03:59:09AM -0500, Laurent Pinchart wrote:
> > > I believe we should follow the first two recommendations of the
> > > Software Freedom Conservancy on using LLM-backed generative AI
> > > systems for FOSS contributions ([1]).
> > > 
> > > [1]
> > > https://sfconservancy.org/llm-gen-ai/llm-backed-generative-ai-recommendations.html
> > >  
> > 
> > It's not clear to me that the SFC document is particularly
> > applicable for the use of LLM's beyond the use case of generating
> > code which is contributed to FOSS projects.
> 
> Agreed: the document there is about AI-generated code ("Generative
> AI"), not about patch review.

In a narrow construction, possibly.  But broadly it seems to be a
charter for the rights of people to ignore AI absolutely and how they
should interact with people who use it: that does have applicability to
AI reviews.

> > Things get a lot more complicated when we're considering the use of
> > LLM's to (a) review code, (b) automate the analysis of a bug report
> > or stack trace, or (c) automate backporting a patch to LTS kernel.
> > 
> > Consider the first recommendation, "The FOSS community should
> > support, not just tolerate, those who outright reject LLM-gen-AI
> > systems."  If someone rejects LLM-gen-AI systems, and the LTS
> > kernel contains patches which are automated backported, and they
> > object, are we bound to forswear the use of automated backport
> > technologies?
> > 
> > What if someone reports a bug with a kernel stack trace, and
> > someone uses an LLM agent to analyze their bug report and find a
> > fix.  What does it mean to "support somone who outright rejects the
> > use of LLM-gen-AI systems" in that case?

I think it's simpler than that: The contributor doesn't get to approve
the tools the maintainer uses to assess and apply patches.  If there's
AI in there and the contributor is an AI luddite, then the patch
doesn't get applied (i.e. your right to ignore AI stops when it
infringes others' right to use it).

Regards,

James

Re: Linking Patchwork with Sashiko?

[Laurent Pinchart]

On Wed, Jul 15, 2026 at 08:42:54AM -0400, James Bottomley wrote:
> On Wed, 2026-07-15 at 09:13 +0200, Mauro Carvalho Chehab wrote:
> > On Tue, 14 Jul 2026 23:54:43 -0400 "Theodore Tso" wrote:
> > > On Wed, Jul 15, 2026 at 03:59:09AM -0500, Laurent Pinchart wrote:
> > > > I believe we should follow the first two recommendations of the
> > > > Software Freedom Conservancy on using LLM-backed generative AI
> > > > systems for FOSS contributions ([1]).
> > > > 
> > > > [1] https://sfconservancy.org/llm-gen-ai/llm-backed-generative-ai-recommendations.html
> > > 
> > > It's not clear to me that the SFC document is particularly
> > > applicable for the use of LLM's beyond the use case of generating
> > > code which is contributed to FOSS projects.
> > 
> > Agreed: the document there is about AI-generated code ("Generative
> > AI"), not about patch review.
> 
> In a narrow construction, possibly.  But broadly it seems to be a
> charter for the rights of people to ignore AI absolutely and how they
> should interact with people who use it: that does have applicability to
> AI reviews.

That is my understanding too. I think the industry broadly defines
"generative AI" as LLM-based tools that generate content traditionally
produced by humans (text and code in this case). I think this applies to
reviews. It does not mean one has to agree with the SFC recommandations
of course.

> > > Things get a lot more complicated when we're considering the use of
> > > LLM's to (a) review code, (b) automate the analysis of a bug report
> > > or stack trace, or (c) automate backporting a patch to LTS kernel.
> > > 
> > > Consider the first recommendation, "The FOSS community should
> > > support, not just tolerate, those who outright reject LLM-gen-AI
> > > systems."  If someone rejects LLM-gen-AI systems, and the LTS
> > > kernel contains patches which are automated backported, and they
> > > object, are we bound to forswear the use of automated backport
> > > technologies?
> > > 
> > > What if someone reports a bug with a kernel stack trace, and
> > > someone uses an LLM agent to analyze their bug report and find a
> > > fix.  What does it mean to "support somone who outright rejects the
> > > use of LLM-gen-AI systems" in that case?
> 
> I think it's simpler than that: The contributor doesn't get to approve
> the tools the maintainer uses to assess and apply patches.  If there's
> AI in there and the contributor is an AI luddite, then the patch
> doesn't get applied (i.e. your right to ignore AI stops when it
> infringes others' right to use it).

I don't think anyone instructed any maintainer to stop using those tools
to assess patches.

On a side note, I find the formulation "contributor *is* an AI luddite"
gets close to an ad hominem attack. I assume it wasn't your intention.
Given how heated this topic is, focussing on people's actions instead of
their nature could help making the discussion more productive (if that's
at all possible on a mailing list).

-- 
Regards,

Laurent Pinchart

Re: Linking Patchwork with Sashiko?

[James Bottomley]

On Wed, 2026-07-15 at 19:18 +0300, Laurent Pinchart wrote:
> On Wed, Jul 15, 2026 at 08:42:54AM -0400, James Bottomley wrote:
> > On Wed, 2026-07-15 at 09:13 +0200, Mauro Carvalho Chehab wrote:
> > > On Tue, 14 Jul 2026 23:54:43 -0400 "Theodore Tso" wrote:
[...]
> > > > Things get a lot more complicated when we're considering the
> > > > use of LLM's to (a) review code, (b) automate the analysis of a
> > > > bug report or stack trace, or (c) automate backporting a patch
> > > > to LTS kernel.
> > > > 
> > > > Consider the first recommendation, "The FOSS community should
> > > > support, not just tolerate, those who outright reject LLM-gen-
> > > > AI systems."  If someone rejects LLM-gen-AI systems, and the
> > > > LTS kernel contains patches which are automated backported, and
> > > > they object, are we bound to forswear the use of automated
> > > > backport technologies?
> > > > 
> > > > What if someone reports a bug with a kernel stack trace, and
> > > > someone uses an LLM agent to analyze their bug report and find
> > > > a fix.  What does it mean to "support somone who outright
> > > > rejects the use of LLM-gen-AI systems" in that case?
> > 
> > I think it's simpler than that: The contributor doesn't get to
> > approve the tools the maintainer uses to assess and apply patches. 
> > If there's AI in there and the contributor is an AI luddite, then
> > the patch doesn't get applied (i.e. your right to ignore AI stops
> > when it infringes others' right to use it).
> 
> I don't think anyone instructed any maintainer to stop using those
> tools to assess patches.

Well, AI replies to patches were the discussion.  That is part of a
maintainer assessment (at least if sashiko replies with a problem to
SCSI patches I ignore the patch until the submitter either fixes the
issue or explains why it is wrong).

> On a side note, I find the formulation "contributor *is* an AI
> luddite" gets close to an ad hominem attack. I assume it wasn't your
> intention. Given how heated this topic is, focussing on people's
> actions instead of their nature could help making the discussion more
> productive (if that's at all possible on a mailing list).

It's a common and neutral dictionary term to mean someone opposed to
change:

https://www.dictionary.com/browse/luddite

If we avoid all words which originally had negative origins because the
origins might cause offence to some, you'll find a long list of
everyday words:

https://www.mentalfloss.com/language/words/13-words-changed-negative-positive-or-vice-versa

Although I personally would love to support banning the word "Dude" in
silicon valley on grounds of original negative connotation ...

Regards,

James

Re: Linking Patchwork with Sashiko?

[Laurent Pinchart]

On Wed, Jul 15, 2026 at 12:53:47PM -0400, James Bottomley wrote:
> On Wed, 2026-07-15 at 19:18 +0300, Laurent Pinchart wrote:
> > On Wed, Jul 15, 2026 at 08:42:54AM -0400, James Bottomley wrote:
> > > On Wed, 2026-07-15 at 09:13 +0200, Mauro Carvalho Chehab wrote:
> > > > On Tue, 14 Jul 2026 23:54:43 -0400 "Theodore Tso" wrote:
> [...]
> > > > > Things get a lot more complicated when we're considering the
> > > > > use of LLM's to (a) review code, (b) automate the analysis of a
> > > > > bug report or stack trace, or (c) automate backporting a patch
> > > > > to LTS kernel.
> > > > > 
> > > > > Consider the first recommendation, "The FOSS community should
> > > > > support, not just tolerate, those who outright reject LLM-gen-
> > > > > AI systems."  If someone rejects LLM-gen-AI systems, and the
> > > > > LTS kernel contains patches which are automated backported, and
> > > > > they object, are we bound to forswear the use of automated
> > > > > backport technologies?
> > > > > 
> > > > > What if someone reports a bug with a kernel stack trace, and
> > > > > someone uses an LLM agent to analyze their bug report and find
> > > > > a fix.  What does it mean to "support somone who outright
> > > > > rejects the use of LLM-gen-AI systems" in that case?
> > > 
> > > I think it's simpler than that: The contributor doesn't get to
> > > approve the tools the maintainer uses to assess and apply patches. 
> > > If there's AI in there and the contributor is an AI luddite, then
> > > the patch doesn't get applied (i.e. your right to ignore AI stops
> > > when it infringes others' right to use it).
> > 
> > I don't think anyone instructed any maintainer to stop using those
> > tools to assess patches.
> 
> Well, AI replies to patches were the discussion.  That is part of a
> maintainer assessment (at least if sashiko replies with a problem to
> SCSI patches I ignore the patch until the submitter either fixes the
> issue or explains why it is wrong).
> 
> > On a side note, I find the formulation "contributor *is* an AI
> > luddite" gets close to an ad hominem attack. I assume it wasn't your
> > intention. Given how heated this topic is, focussing on people's
> > actions instead of their nature could help making the discussion more
> > productive (if that's at all possible on a mailing list).
> 
> It's a common and neutral dictionary term to mean someone opposed to
> change:
> 
> https://www.dictionary.com/browse/luddite

It was the conjunction with *is* in that formulation that triggered me
(and before anyone sends a meme involving Bill Clinton: pleast don't).
It puts people in boxes and that doesn't help discussions. But we're
digressing, I don't think this is worth debating here.

> If we avoid all words which originally had negative origins because the
> origins might cause offence to some, you'll find a long list of
> everyday words:
> 
> https://www.mentalfloss.com/language/words/13-words-changed-negative-positive-or-vice-versa
> 
> Although I personally would love to support banning the word "Dude" in
> silicon valley on grounds of original negative connotation ...

:-D

-- 
Regards,

Laurent Pinchart

Re: Linking Patchwork with Sashiko?

[Laurent Pinchart]

Hi Ted,

On Tue, Jul 14, 2026 at 11:54:43PM -0400, Theodore Tso wrote:
> On Wed, Jul 15, 2026 at 03:59:09AM -0500, Laurent Pinchart wrote:
> > I believe we should
> > follow the first two recommendations of the Software Freedom Conservancy
> > on using LLM-backed generative AI systems for FOSS contributions ([1]).
> > 
> > [1] https://sfconservancy.org/llm-gen-ai/llm-backed-generative-ai-recommendations.html
> 
> It's not clear to me that the SFC document is particularly applicable
> for the use of LLM's beyond the use case of generating code which is
> contributed to FOSS projects.
> 
> Things get a lot more complicated when we're considering the use of
> LLM's to (a) review code, (b) automate the analysis of a bug report or
> stack trace, or (c) automate backporting a patch to LTS kernel.
> 
> Consider the first recommendation, "The FOSS community should support,
> not just tolerate, those who outright reject LLM-gen-AI systems."  If
> someone rejects LLM-gen-AI systems, and the LTS kernel contains
> patches which are automated backported, and they object, are we bound
> to forswear the use of automated backport technologies?

I think this is a bit of an extreme example that does not reflect the
rationale for the SFC recommandations. Note recommendation 3, which
states

"FOSS projects should not shun contributors who choose to use LLM-gen-AI
systems"

I hold personal opinions on what I consider is or isn't ethical in this
context, and I also understand that ethical principles have a personal
dimension. Within the boundaries of the rules of our community, people
should be entitled to have different opinions. I don't think anyone is
seriously trying to *force* the whole kernel community to ban usage of
generative AI (believing in chances of complete success would be a bit
foolish at this time), not even the people having the most extreme moral
compasses pointing towards that direction.

> What if someone reports a bug with a kernel stack trace, and someone
> uses an LLM agent to analyze their bug report and find a fix.  What
> does it mean to "support somone who outright rejects the use of
> LLM-gen-AI systems" in that case?

My interpretation (which conveniently matches my opinion) is that
developers should not be forced to directly *use* generative AI tools,
and should not be forced to *process* unfiltered output of those tools.

What does this translate to in practice ? I will need to sleep over it
for at least a few nights to formulate it clearly. I know that I (along
numerous other people) have strong negative feelings if forced to
justify myself against unchecked output of an LLM-based review bot, or
to review patches where the submitter has clearly not invested
substantial time in making the contributions as good as they can. When
this happens with human reviewers or developers, they lose trust points
and end up being ignored. I don't want to be forced to hold LLMs in
higher regards than that.

If you use generative AI to detect issues, find an actionable comment
after careful verification and tell me why you find it actionable, I
will treat it as a review from Ted Ts'o. I may think your moral compass
isn't tuned as mine, but I can still hold you in high regard despite
differences in opinions. I certainly wouldn't ignore a serious security
issue you would report in that way.

If you start letting obvious false positives through your filter, or
significantly more false positives, then my trust in your reviews and
skills as a maintainer will diminish over time. The same would apply if
you started rambling nonsensically on your own. Occasional mistakes will
likely have little impact as we all make mistakes, especially if you
acknowledged such mistakes.

What this does *not* mean to me is creating an environment where we
pretend those technologies don't exist. The "put your head in the sand"
comment from Linus elsewhere in this thread is a bit of a
mischaracterization. To his defence, discussions on this topic on kernel
mailing lists have been quite heated and prone to mischaracterization.

I have talked with multiple people across the whole spectrum from
neutral to very negative opinions about generative AI. One thing that
struck me is how a large number of those people feel they're not allowed
to express any opinion that is not strongly pro-AI. Maybe listening to
each other could be a good first step towards better understanding. I
hope we as a community share enough common values to consider important
for everybody to feel heard.

On a side note, I have submitted a BoF proposal on this topic for the
OSS Europe conference (quite ironically, in the AI track). The goal is
to give a place for the people who feel the community only listens to
the pro-AI voices and rejects all other opinions. I don't know if it
will be accepted.

> > I expect maintainers who want to act on sashiko reviews to triage and
> > verify them first before bothering authors
> 
> As a maintainer, I don't believe I should be forced to rephrase a
> Sashiko report just because a patch author "outright rejects" LLM's.

I don't think I have called for that. What I believe is that triaging
LLM reviews should not be forced onto contributors.

> For that matter, I don't believe I'm obliged to accept patches from
> someone who forces me to do extra work because they refuse to look at
> Sashiko reviews....

Flipping the argument, should contributors be obliged to do extra work
that make them feel diminished as a human ? I'm talking here about
justifying themselves against LLM arguments that have not been analyzed
by a maintainer first.

> How do we balance the needs and time of maintainers with patch
> authors?  I don't think it's obvious that we *MUST* bend over
> backwards to oblige the needs of all patch authors.

Does the above bring some clarification to this question, or at least
useful examples to continue a constructive discussion ?

-- 
Regards,

Laurent Pinchart

Re: Linking Patchwork with Sashiko?

[Jan Kara]

Hi Laurent!

On Wed 15-07-26 19:11:11, Laurent Pinchart wrote:
> On Tue, Jul 14, 2026 at 11:54:43PM -0400, Theodore Tso wrote:
> > On Wed, Jul 15, 2026 at 03:59:09AM -0500, Laurent Pinchart wrote:
> > > I believe we should
> > > follow the first two recommendations of the Software Freedom Conservancy
> > > on using LLM-backed generative AI systems for FOSS contributions ([1]).
> > > 
> > > [1] https://sfconservancy.org/llm-gen-ai/llm-backed-generative-ai-recommendations.html
> > 
> > It's not clear to me that the SFC document is particularly applicable
> > for the use of LLM's beyond the use case of generating code which is
> > contributed to FOSS projects.
> > 
> > Things get a lot more complicated when we're considering the use of
> > LLM's to (a) review code, (b) automate the analysis of a bug report or
> > stack trace, or (c) automate backporting a patch to LTS kernel.
> > 
> > Consider the first recommendation, "The FOSS community should support,
> > not just tolerate, those who outright reject LLM-gen-AI systems."  If
> > someone rejects LLM-gen-AI systems, and the LTS kernel contains
> > patches which are automated backported, and they object, are we bound
> > to forswear the use of automated backport technologies?
> 
> I think this is a bit of an extreme example that does not reflect the
> rationale for the SFC recommandations. Note recommendation 3, which
> states
> 
> "FOSS projects should not shun contributors who choose to use LLM-gen-AI
> systems"
> 
> I hold personal opinions on what I consider is or isn't ethical in this
> context, and I also understand that ethical principles have a personal
> dimension. Within the boundaries of the rules of our community, people
> should be entitled to have different opinions. I don't think anyone is
> seriously trying to *force* the whole kernel community to ban usage of
> generative AI (believing in chances of complete success would be a bit
> foolish at this time), not even the people having the most extreme moral
> compasses pointing towards that direction.
> 
> > What if someone reports a bug with a kernel stack trace, and someone
> > uses an LLM agent to analyze their bug report and find a fix.  What
> > does it mean to "support somone who outright rejects the use of
> > LLM-gen-AI systems" in that case?
> 
> My interpretation (which conveniently matches my opinion) is that
> developers should not be forced to directly *use* generative AI tools,
> and should not be forced to *process* unfiltered output of those tools.
> 
> What does this translate to in practice ? I will need to sleep over it
> for at least a few nights to formulate it clearly. I know that I (along
> numerous other people) have strong negative feelings if forced to
> justify myself against unchecked output of an LLM-based review bot, or
> to review patches where the submitter has clearly not invested
> substantial time in making the contributions as good as they can. When
> this happens with human reviewers or developers, they lose trust points
> and end up being ignored. I don't want to be forced to hold LLMs in
> higher regards than that.

I'm not sure I understand here. Do you say you have moral issues if you
should read unchecked LLM output? Or is it just that you find noise /
signal ratio too bad with LLM output so you find it a waste of your time
(and thus feel badly if you were forced to waste this time)? Or something
else?

> > > I expect maintainers who want to act on sashiko reviews to triage and
> > > verify them first before bothering authors
> > 
> > As a maintainer, I don't believe I should be forced to rephrase a
> > Sashiko report just because a patch author "outright rejects" LLM's.
> 
> I don't think I have called for that. What I believe is that triaging
> LLM reviews should not be forced onto contributors.

Frankly, so far I see the issue with LLM review similarly as a dillema we
used to have with checkpatch. It was finding some sensible issues but often
the suggestions were also misleading. So some people just found it a waste
of time and ignored it, other people didn't accept patches if it didn't
pass checkpatch.

I guess nobody can really force contributors to read LLM reviews but OTOH
if you see LLM review keeps finding real issues in the work of some
contributor and you as a maintainer have to go and filter them for the
contributor (instead of contributor doing this work on their own), then you
naturally reduce priority of such contributions because it is more work for
you as a maintainer to deal with them...
 
> > For that matter, I don't believe I'm obliged to accept patches from
> > someone who forces me to do extra work because they refuse to look at
> > Sashiko reviews....
> 
> Flipping the argument, should contributors be obliged to do extra work
> that make them feel diminished as a human ? I'm talking here about
> justifying themselves against LLM arguments that have not been analyzed
> by a maintainer first.

You write here about "feeling diminished" or "justifying themselves" and
I'm not sure I get it. If you get a complaint from some CI running
checkpatch or say coverity which is bogus (or perhaps correct?), do you
also feel diminished or needing to justify? I just don't see how LLMs are
different here... And just to be sure: I'm genuinely trying to understand
your position because so far I don't understand it.

For example when I get Sashiko feedback for my patches, I just ignore the
comments I find bogus and address those that I find to the point in the
next revision. If I see Sashiko found something fundamental, I'll also
reply to the thread to notify human reviewers that I'll have to do a larger
rewrite so they don't have to waste human time with reviewing this version
of the patches.

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

Re: Linking Patchwork with Sashiko?

[Theodore Tso]

On Wed, Jul 15, 2026 at 07:11:11PM -0500, Laurent Pinchart wrote:
> My interpretation (which conveniently matches my opinion) is that
> developers should not be forced to directly *use* generative AI tools,
> and should not be forced to *process* unfiltered output of those tools.

But maintaineres should be forced to process the output of those tools
because the developers refuses to do that work?  If someone refuses to
use the unfiltered otuput of those tools, and their code *is* buggy, I
may not have time to cater to these people.  In which case, if I see
that their code is reliably buggy, and they are refusing to look at
the review from the LLM (or the zero-day kernel bot, or
checkpatch.pl), I reserve the right to just start ignoring patches
from those people.

> 
> I don't think I have called for that. What I believe is that triaging
> LLM reviews should not be forced onto contributors.

I don't believe that triaging LLM revoews should be forced onto the
maintainers.  Remember, the contributors outnumber the maintainers, so
forcing more work on maintainers don't scale.  One of the reasons why
I was so excited for Sashiko is that it reduced the load on
maintainers, while improving the quality of patch reviews.

> Flipping the argument, should contributors be obliged to do extra work
> that make them feel diminished as a human ? I'm talking here about
> justifying themselves against LLM arguments that have not been analyzed
> by a maintainer first.

Nope; but I don't believe I'm obliged to accept contributions from
people who feel that way....

						- Ted

Re: Linking Patchwork with Sashiko?

[Miguel Ojeda]

On Wed, Jul 15, 2026 at 7:15 PM Theodore Tso <tytso@mit.edu> wrote:
>
> I don't believe that triaging LLM revoews should be forced onto the
> maintainers.  Remember, the contributors outnumber the maintainers, so
> forcing more work on maintainers don't scale.

Indeed.

And even if a maintainer has the time to read carefully every AI
comment on every patch, in an ideal world it would still be good to
have the authors read them too, because then the chance of
disregarding a true positive is lower.

After all, the authors are the ones that have the context of the patch
since they just submitted it. That is, they are the best placed ones
to filter feedback that arrives soon after the patch is sent, AI or
not.

Of course, mistakes can happen, and there will be instances where a
confused AI may confuse an author to change the code for the worse.
But as long as we consider the result a net positive, it should be
fine.

This is the position I gave Roman back then, and when we enabled
"reply to author" in Sashiko, we did see authors engaging with the
reports. That actually saves time for maintainers (and reviewers) in some cases.

In fact, at least one person asked about running Sashiko (or the
prompts) on their end to get their patches "AI-clean" (to some degree)
before sending them to the list. That is good -- it is like getting a
patch lint-clean before submitting.

Cheers,
Miguel

Re: Linking Patchwork with Sashiko?

[Laurent Pinchart]

On Wed, Jul 15, 2026 at 01:14:57PM -0400, Theodore Tso wrote:
> On Wed, Jul 15, 2026 at 07:11:11PM -0500, Laurent Pinchart wrote:
> > My interpretation (which conveniently matches my opinion) is that
> > developers should not be forced to directly *use* generative AI tools,
> > and should not be forced to *process* unfiltered output of those tools.
> 
> But maintaineres should be forced to process the output of those tools
> because the developers refuses to do that work?

Maintainers (at least some of them) are the ones introducing a change in
the process here. I feel there's some sort of sense of panic among a
part of the kernel maintainers, or maybe such an acute burn out, that it
justifies anyone with different opinions being treated as collateral
damage.

Is there really no acceptable option beside forcing everybody to swallow
the generative AI pill ? No option for people with ethics concern to be
still considered part of the kernel community ? No option but complete
surrender and pledging allegiance ? This is how I increasingly feel
being treated, and I know I'm not alone.

> If someone refuses to
> use the unfiltered otuput of those tools, and their code *is* buggy, I
> may not have time to cater to these people.  In which case, if I see
> that their code is reliably buggy, and they are refusing to look at
> the review from the LLM (or the zero-day kernel bot, or
> checkpatch.pl), I reserve the right to just start ignoring patches
> from those people.

Please, let's stop comparing generative AI with zero-day kernel bot or
checkpatch. That's not a relevant comparison.

> > I don't think I have called for that. What I believe is that triaging
> > LLM reviews should not be forced onto contributors.
> 
> I don't believe that triaging LLM revoews should be forced onto the
> maintainers.  Remember, the contributors outnumber the maintainers, so
> forcing more work on maintainers don't scale.

I see many people claiming that LLMs drastically lower the review
burden. Does it do so only marginally, is effort to triage reviews
higher than the effort to write reviews in the first place ?

There's also an elephant in the room: beside paying for the tokens used
by sashiko, I'm sure Google could also affort funding developers and
maintainers to perform triage. That's a bit of a different question, but
it does feel that two byproducts of sashiko useful for Google are to
trick maintainers into forcing contributors to use generative AI, and to
be seen as helping the community without having to address the core,
long-term issue of underfunded maintainers.

> One of the reasons why
> I was so excited for Sashiko is that it reduced the load on
> maintainers, while improving the quality of patch reviews.
> 
> > Flipping the argument, should contributors be obliged to do extra work
> > that make them feel diminished as a human ? I'm talking here about
> > justifying themselves against LLM arguments that have not been analyzed
> > by a maintainer first.
> 
> Nope; but I don't believe I'm obliged to accept contributions from
> people who feel that way....

You're not obliged to accept contributions from anyone until Linus
forces you. That doesn't mean discriminating contributors based on their
beliefs would be a good idea.

-- 
Regards,

Laurent Pinchart

Re: Linking Patchwork with Sashiko?

[Linus Torvalds]

On Wed, 15 Jul 2026 at 10:42, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
>
> Please, let's stop comparing generative AI with zero-day kernel bot or
> checkpatch. That's not a relevant comparison.

You are correct. The AI generated reports are usually much superior
and more flexible.

They aren't just syntax highlighters or reporting "this doesn't
build", they actually find real non-trivial problems.

Now, I'm not saying that one replaces the other. The zero-day bot
finding things that don't even build or boot are great. That's a
pretty hard and clear signal.

But the AI reports are often a lot better than checkpatch reports have been.

Those checkpatch reports have gone through years of trying to massage
them into something that adds more value than pain - and I do think
we're there now, but it really required that effort on the part of
checkpatch maintainers.

And that's exactly the kind of effort we need for Sashiko and friends.

Because no, AI reports are not always great, but neither are human
reviews. I see less useful reviews by humans where I go "did this
person just try to get his name in the commit log, because that has no
useful content".

I suspect you haven't used AI for programming. Try it. Try one of the
*good* ones.

And I don't mean "use it for the kernel". Use it just for the fun of
it. Find something you want to do, and just play with it.

The open models are getting pretty darn good too, but for a first
trial without any real setup, one of the free tiers of the cloud ones
is certainly the easiest way to just kick the tires.

Do it with something you find interesting, but not "important" - start
small, and start with something you feel you probably wouldn't really
waste your time on if it was just yourself, but where you have enough
background knowledge that you can judge the output.

It's what I did, because I wanted to judge things based on real use,
not on what others say (and sometimes the loudest ones do it for
marketing reasons because they have stock that is tied to it).

You might find it enlightening, or at least interesting.

My own personal annoyance was how eager to please AI models tend to be
at least by default. I understand why it happens, and that people like
that subservient tone, but at least personally I was looking for more
critical review of the code, not an AI that had been taught to say
"You are entirely right" just to please people.

          Linus

Re: Linking Patchwork with Sashiko?

[Ihor Solodrai]

On 7/14/26 5:59 PM, Laurent Pinchart wrote:
> [...]
> 
> I expect maintainers who want to act on sashiko reviews to triage and
> verify them first before bothering authors, yes.

I can't help but chime in, because I find this opinion triggeringly
unreasonable.

As of today, the problem is *not* "thoughtful experts are bombarded
with low-quality feedback from llms", even though the experts might
feel like that frequently.

The problem is that the mailing list is flooded with slop to varying
degree depending on the subsystem. And review by humans, even with
powerful AI tools at hand, doesn't scale [1][2].

And the argument "I didn't sign up for AI reviews" is weak. If you've
sent a patch to the mailing list, and there are maintainer-sanctioned
bot messages in response, you've already opted-in to receive them.

Yes, it is annoying. It's annoying in the same way a dozen nits on
your patch from a human reviewer is annoying. But the contributors
generally accept this, otherwise their patches don't land.

Your job as a contributor is to make sure the patch is "good enough"
to land. Now, with ubiquitous AI tools, "good enough" means *at least*
that the AI bots don't find real bugs.

Yes, assessing whether AI report is "real" is work, but it's not
reasonable to push this work on already overwhelmed maintainers. And
if AI is wrong, again it's the job of the author to convince the
maintainers it's wrong.

I set up automated AI code reviews on BPF list using Chris Mason's
prompts in the fall last year [3], before sashiko was developed. And
originally we were very worried about the quality of the reviews.

Time has showed that we had to be more worried about the average
quality of incoming patch instead.

[1] https://lore.kernel.org/bpf/CAADnVQKsM8iOGO3ZL3LgbWigOBBMrGbTYZ_k_Ktz=+cVkvRLXg@mail.gmail.com/
[2] https://lore.kernel.org/all/20260703-vfs-summer-jam-22b2edbbbc44@brauner/
[3] https://lore.kernel.org/all/0d6aa077-1222-49a0-9554-dd922122a904@meta.com/

> I believe we should
> follow the first two recommendations of the Software Freedom Conservancy
> on using LLM-backed generative AI systems for FOSS contributions ([1]).
> 
> [1] https://sfconservancy.org/llm-gen-ai/llm-backed-generative-ai-recommendations.html
> 

Re: Linking Patchwork with Sashiko?

[Laurent Pinchart]

On Wed, Jul 15, 2026 at 09:28:03AM -0700, Ihor Solodrai wrote:
> On 7/14/26 5:59 PM, Laurent Pinchart wrote:
> > [...]
> > 
> > I expect maintainers who want to act on sashiko reviews to triage and
> > verify them first before bothering authors, yes.
> 
> I can't help but chime in, because I find this opinion triggeringly
> unreasonable.
> 
> As of today, the problem is *not* "thoughtful experts are bombarded
> with low-quality feedback from llms", even though the experts might
> feel like that frequently.
> 
> The problem is that the mailing list is flooded with slop to varying
> degree depending on the subsystem. And review by humans, even with
> powerful AI tools at hand, doesn't scale [1][2].

I certainly agree with you that this is a large problem. I don't think
we have a single problem though, but I can understand people who
consider the problem you're discribing as more urgent to address.

> And the argument "I didn't sign up for AI reviews" is weak. If you've
> sent a patch to the mailing list, and there are maintainer-sanctioned
> bot messages in response, you've already opted-in to receive them.

We're enabling bots on mailing lists that people are already subscribed
to. But I don't think that's a very important argument here.

> Yes, it is annoying. It's annoying in the same way a dozen nits on
> your patch from a human reviewer is annoying.

That I strongly disagree with. A humain reviewer sending a review with
dozens of nits usually doesn't annoy me, and doesn't make me feel
diminished as a human.

> But the contributors
> generally accept this, otherwise their patches don't land.
> 
> Your job as a contributor is to make sure the patch is "good enough"
> to land. Now, with ubiquitous AI tools, "good enough" means *at least*
> that the AI bots don't find real bugs.
> 
> Yes, assessing whether AI report is "real" is work, but it's not
> reasonable to push this work on already overwhelmed maintainers. And
> if AI is wrong, again it's the job of the author to convince the
> maintainers it's wrong.

We disagree on this as well. This would force contributors to constantly
justify their value against a machine that is known to produce a
non-negligible quantity of nonsense. Furthermore, if those generative AI
tools are as good as their supporters claim, the time they free for
maintainers should outweight the need workload to triage the comments.

> I set up automated AI code reviews on BPF list using Chris Mason's
> prompts in the fall last year [3], before sashiko was developed. And
> originally we were very worried about the quality of the reviews.
> 
> Time has showed that we had to be more worried about the average
> quality of incoming patch instead.
> 
> [1] https://lore.kernel.org/bpf/CAADnVQKsM8iOGO3ZL3LgbWigOBBMrGbTYZ_k_Ktz=+cVkvRLXg@mail.gmail.com/
> [2] https://lore.kernel.org/all/20260703-vfs-summer-jam-22b2edbbbc44@brauner/
> [3] https://lore.kernel.org/all/0d6aa077-1222-49a0-9554-dd922122a904@meta.com/
> 
> > I believe we should
> > follow the first two recommendations of the Software Freedom Conservancy
> > on using LLM-backed generative AI systems for FOSS contributions ([1]).
> > 
> > [1] https://sfconservancy.org/llm-gen-ai/llm-backed-generative-ai-recommendations.html

-- 
Regards,

Laurent Pinchart

Re: Linking Patchwork with Sashiko?

[Ihor Solodrai]

On 7/15/26 9:39 AM, Laurent Pinchart wrote:
> On Wed, Jul 15, 2026 at 09:28:03AM -0700, Ihor Solodrai wrote:
>> On 7/14/26 5:59 PM, Laurent Pinchart wrote:
>>> [...]
>>
>> Yes, assessing whether AI report is "real" is work, but it's not
>> reasonable to push this work on already overwhelmed maintainers. And
>> if AI is wrong, again it's the job of the author to convince the
>> maintainers it's wrong.
> 
> We disagree on this as well. This would force contributors to constantly
> justify their value against a machine that is known to produce a
> non-negligible quantity of nonsense.

I know what you mean and I can relate. Going through walls of
AI-generated paragraphs is not fun, to put it lightly.

However it seems that you are suggesting to simply delegate this work
to maintainers, and I very much disagree with that approach (even
though I'm not a maintainer myself).

I hope you're not saying "let's just not use AI", because that ship
has sailed a while ago.

And if automated AI reviews are there, someone has to do the
triage. AI can do the triage itself only to a limited degree. For
example, there are instructions in review-prompts where AI checks
whether an issue has already been discussed. But it will never be
perfect.

I think it makes much more sense for the author of the patch to do the
triage, as they have the best context of the work, and they are
usually the most invested in their patch being merged in.

> Furthermore, if those generative AI
> tools are as good as their supporters claim, the time they free for
> maintainers should outweight the need workload to triage the comments.

Even if the AI tools were ~perfect with respect to code review, I
think people would still be signing off patches and taking
responsibility for them.

An imaginary perfect AI reviewer that maintainer can trust to land
code without looking at it would essentially become an AI maintainer.
Independent of whether you think it's possible, it hasn't happened
yet, so we have to deal with imperfect AI in the meanwhile.


> >> I set up automated AI code reviews on BPF list using Chris Mason's
>> prompts in the fall last year [3], before sashiko was developed. And
>> originally we were very worried about the quality of the reviews.
>>
>> Time has showed that we had to be more worried about the average
>> quality of incoming patch instead.
>>
>> [1] https://lore.kernel.org/bpf/CAADnVQKsM8iOGO3ZL3LgbWigOBBMrGbTYZ_k_Ktz=+cVkvRLXg@mail.gmail.com/
>> [2] https://lore.kernel.org/all/20260703-vfs-summer-jam-22b2edbbbc44@brauner/
>> [3] https://lore.kernel.org/all/0d6aa077-1222-49a0-9554-dd922122a904@meta.com/
>>
>>> I believe we should
>>> follow the first two recommendations of the Software Freedom Conservancy
>>> on using LLM-backed generative AI systems for FOSS contributions ([1]).
>>>
>>> [1] https://sfconservancy.org/llm-gen-ai/llm-backed-generative-ai-recommendations.html
> 

Re: Linking Patchwork with Sashiko?

[Mark Brown]

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

On Wed, Jul 15, 2026 at 10:12:03AM -0700, Ihor Solodrai wrote:
> On 7/15/26 9:39 AM, Laurent Pinchart wrote:
> > On Wed, Jul 15, 2026 at 09:28:03AM -0700, Ihor Solodrai wrote:

> >> Yes, assessing whether AI report is "real" is work, but it's not
> >> reasonable to push this work on already overwhelmed maintainers. And
> >> if AI is wrong, again it's the job of the author to convince the
> >> maintainers it's wrong.

> > We disagree on this as well. This would force contributors to constantly
> > justify their value against a machine that is known to produce a
> > non-negligible quantity of nonsense.

> I know what you mean and I can relate. Going through walls of
> AI-generated paragraphs is not fun, to put it lightly.

> However it seems that you are suggesting to simply delegate this work
> to maintainers, and I very much disagree with that approach (even
> though I'm not a maintainer myself).

This is something that already happens with human written reviews,
indeed I have a canned reply for one particular reviewer telling
submitters it's OK to ignore them.  It goes in both directions - it can
be ignoring some issues or postponing them for later, or it can be
making sure that there's input from particular people.

> I think it makes much more sense for the author of the patch to do the
> triage, as they have the best context of the work, and they are
> usually the most invested in their patch being merged in.

It's not clear cut - untrustworthy tooling often causes problems, I'm
fairly sure I'm seeing issues that are the result of submitters getting
mislead by LLM reviews in a similar manner to some compiler warnings.

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

Re: Linking Patchwork with Sashiko?

[Ihor Solodrai]

On 7/15/26 10:35 AM, Mark Brown wrote:
> On Wed, Jul 15, 2026 at 10:12:03AM -0700, Ihor Solodrai wrote:
>> On 7/15/26 9:39 AM, Laurent Pinchart wrote:
>>> On Wed, Jul 15, 2026 at 09:28:03AM -0700, Ihor Solodrai wrote:
> 
>>>> Yes, assessing whether AI report is "real" is work, but it's not
>>>> reasonable to push this work on already overwhelmed maintainers. And
>>>> if AI is wrong, again it's the job of the author to convince the
>>>> maintainers it's wrong.
> 
>>> We disagree on this as well. This would force contributors to constantly
>>> justify their value against a machine that is known to produce a
>>> non-negligible quantity of nonsense.
> 
>> I know what you mean and I can relate. Going through walls of
>> AI-generated paragraphs is not fun, to put it lightly.
> 
>> However it seems that you are suggesting to simply delegate this work
>> to maintainers, and I very much disagree with that approach (even
>> though I'm not a maintainer myself).
> 
> This is something that already happens with human written reviews,
> indeed I have a canned reply for one particular reviewer telling
> submitters it's OK to ignore them.  It goes in both directions - it can
> be ignoring some issues or postponing them for later, or it can be
> making sure that there's input from particular people.

My objection is to a suggested expectation for every review to be
triaged by maintainers/reviewers *before* it's sent or the author
engages with it.

I think the author should be the first one to engage, it's a feedback
on their patch after all. And of course reviewers/maintainers are free
to jump in whenever they can and feel it's necessary, and they do. Opt-in.

> 
>> I think it makes much more sense for the author of the patch to do the
>> triage, as they have the best context of the work, and they are
>> usually the most invested in their patch being merged in.
> 
> It's not clear cut - untrustworthy tooling often causes problems, I'm
> fairly sure I'm seeing issues that are the result of submitters getting
> mislead by LLM reviews in a similar manner to some compiler warnings.

Yes, this is a valid point. I'm not arguing automated AI feedback is
always good. This is why the triage is needed in the first place.

I think one small thing that may help with this is teaching
contributors to not iterate on the revisions too quickly based solely
on AI feedback. And also try to iterate with AI reviews off-list first.

But that's marginal. Fundamentally, a human has to read AI feedback on
the patch in the end. I don't see a way around it, barring the singularity™.

Re: Linking Patchwork with Sashiko?

[Jason Gunthorpe]

On Wed, Jul 15, 2026 at 07:39:21PM +0300, Laurent Pinchart wrote:
> > Yes, assessing whether AI report is "real" is work, but it's not
> > reasonable to push this work on already overwhelmed maintainers. And
> > if AI is wrong, again it's the job of the author to convince the
> > maintainers it's wrong.
> 
> We disagree on this as well. This would force contributors to constantly
> justify their value against a machine that is known to produce a
> non-negligible quantity of nonsense. Furthermore, if those generative AI
> tools are as good as their supporters claim, the time they free for
> maintainers should outweight the need workload to triage the comments.

I feel Sashiko and this whole AI world has created alot more work. It
is not saving time at all. Now I have to go and read every Sashiko
report to see if there is something important that normal review
missed. I have fix all the drive by 'this is already broken' stuff it
finds. We get way more patches than we did before. Now *everything*
has to be looked at more skeptically if came from some AI slop. I get
crazy real security reports that need special hand holding now that we
never got before.

Even on the submitting side now I have to run patches through all
kinds of AI tools to have a solid chance to navigate the new guantlet
upstream.

We aren't saving time, or creating less work. My hope is we are
creating better quality, higher security and less bugs.

Jason