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