Re: RFC: Enable Sashiko code reviews for

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

> On Sep 2, 2026, at 10:59 AM, David Matlack <dmatlack@google.com> wrote:
> 
> On Wed, Sep 2, 2026 at 2:18 AM Pratyush Yadav <pratyush@kernel.org> wrote:
>> 
>> +Cc Roman because I am complaining about Sashiko ;-)
>> 
>>> On Wed, Sep 02 2026, Baoquan He wrote:
>>> 
>>> On 09/02/26 at 11:04am, Mike Rapoport wrote:
>>>> Hi Baoquan,
>>>> 
>>>> On Wed, Sep 02, 2026 at 01:52:51PM +0800, Baoquan He wrote:
>>>>> On 09/02/26 at 07:34am, Mike Rapoport wrote:
>>>>>> On Tue, Sep 01, 2026 at 01:27:34PM -0700, David Matlack wrote:
>>>>>>> Hi kexec@ mailing list and maintainers,
>>>>>>> 
>>>>>>> I would like to enable Sashiko code reviews for patches sent to the
>>>>>>> kexec mailing list. I have found it useful for patches I have sent and
>>>>>>> reviewed on the kvm and linux-pci mailing lists, which have Sashiko
>>>>>>> enabled.
>>>>>>> 
>>>>>>> I sent a pull request to Sashiko to add kexec here:
>>>>>>> 
>>>>>>>  https://github.com/sashiko-dev/sashiko/pull/474
>>>>>> 
>>>>>> diff --git a/sashiko.dev/email_policy.toml b/sashiko.dev/email_policy.toml
>>>>>> index e6e4fb57f..e9ad97708 100644
>>>>>> --- a/sashiko.dev/email_policy.toml
>>>>>> +++ b/sashiko.dev/email_policy.toml
>>>>>> @@ -175,6 +175,12 @@ reply_to_author = false
>>>>>> cc_individuals = false
>>>>>> cc = ["Chuck Lever <cel@kernel.org>", "Jeff Layton <jlayton@kernel.org>", "Anna Schumaker <anna@kernel.org>"]
>>>>>> 
>>>>>> +[subsystems.kexec]
>>>>>> +lists = ["kexec@lists.infradead.org"]
>>>>>> +reply_to_author = true
>>>>>> +send_positive_review = true
>>>>>> 
>>>>>> Do we really want those?
>>>>> 
>>>>> Some components don't want to CC list, then other people are welcome to
>>>>> drop any comment during reviewing, while cc to maintainer and author
>>>>> looks good to me. Just an input, no objection to any move.
>>>> 
>>>> Sorry, I wasn't clear, I meant do we really want extra emails saying
>>>> sashiko is happy?
>>> 
>>> Oh, sorry. I misunderstood, I thought you had agreed to introduce
>>> sashiko to part of list/author/maintainer or all.
>>> 
>>> I think there are two different ways and they have different impact:
>>> 
>>> 1) CC list (CC author and maintainer can be ignored beause all people
>>> can see it)
>> 
>> This is a side topic, but if we only Cc the list then Sashiko won't Cc
>> the other people in the thread, like the usual "reply to all" every mail
>> clients does. It will _only_ Cc the list. See [0] for example.
>> 
>> I don't think that is a good idea, because Sashiko might complain about
>> something, and then the patch author can reply to the complaint. People
>> who are not subscribed to the list will neither see Sashiko's complaint
>> nor the author's response. So they lose a useful part of the patch
>> review process.
>> 
>> I am one of those people. I don't subscribe to any mailing lists and
>> instead use lei [1] to fetch them. I treat my inbox as the primary
>> stream of patches, and then glance at the lists every now and then. If I
>> get some patches in my inbox but then I don't get any of the follow-ups
>> from the author to Sashiko, that's annoying. Sure, I might see them on
>> the list later, but it is still annoying.

It feels like there are two types of people: some know how to use email filters and some don’t.
Unfortunately, the latter group is often very vocal about what they don’t want
to see on mailing lists. I can easily see the problem with too much ai-generated noise
(and useful information as well), so no complaints from me, just saying that there is a reason
sashiko is fairly conservative here.

>> 
>> And of course, there might be patches that touch multiple subsystems and
>> maintainers of that subsystem might not subscribe to or track kexec@ at
>> all. So they will entirely miss the conversation.
>> 
>> If Sashiko is useful enough to send replies on the list, then I think it
>> is useful enough to reply to everyone.
> 
> It looks like this can be configured:
> 
> - reply_all=true will have Sashiko reply to everyone on the To/Cc line.
> - cc_individuals=true will have Sashiko include all inidividuals from the
>   To/Cc line of the original patch.
> 
>> 
>> IIRC some people have complained in the past about automatically getting
>> replies from Sashiko so maybe that is why this behaviour exists? Roman,
>> is that correct? Is there any appetite yet to change that behaviour?

Can you, please, describe, what behavior do you want?

>> 
>> Or could we perhaps have an unsubscribe mechanism where people who don't
>> want to see anything from Sashiko can unsubscribe themselves and Sashiko
>> will skip them when replying?

This is the territory I don’t really want to go, honestly. Not a dealbreaker if there is a very strong
reason to implement it, but I don’t think we have similar lists for other tools like syzbot or the build verifier.
I feel it’s more about the politics around ai then a real technical reason (it’s like super trivial to drop emails from
a specific sender), so I’d avoid this if possible.

Thanks

>> 
>> [0] https://lore.kernel.org/kvm/20260902072059.90ADC1F000E9@smtp.kernel.org/
>> [1] https://public-inbox.org/lei.txt
>> 
>>>  This equals to cc author and push other reviewers away. And no
>>>  reviewers will be patient and curious enough to check the sashiko
>>>  report except of maintainers. Because maintainers need pick patch
>>>  and may check if all reported issues are handled;
>>> 
>>> 2) Cc maintainers when patch is cooked
>>>  Maintainers tell patch author to check the report. Maybe CC patch
>>>  author directly can save maintainers' effort.
>>> 
>>> I personally think 2) is good. About whether introducing sashiko,
>>> I would vote yes. I buy token by myself, sashiko would be a plus.
>> 
>> FWIW, Sashiko already tracks the kexec@ list and you can see all the
>> patches in the web interface [2]. So you don't need to burn your tokens
>> on reviewing kexec patches ;-)
>> 
>> What David is proposing is to send those reviews to the list.
>> 
>> [2] https://sashiko.dev/#/?list=org.infradead.lists.kexec
>> 
>>> 
>>> Thanks
>>> Baoquan
>> 
>> --
>> Regards,
>> Pratyush Yadav