Re: Linking Patchwork with Sashiko?

[Mauro Carvalho Chehab <mchehab+huawei@kernel.org>]

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