Re: Linking Patchwork with Sashiko?

[Roman Gushchin <roman.gushchin@linux.dev>]

> 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.