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?

[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, 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?

[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!