From: Pratyush Yadav <pratyush@kernel.org>
To: Roman Gushchin <roman.gushchin@linux.dev>
Cc: David Matlack <dmatlack@google.com>,
Pratyush Yadav <pratyush@kernel.org>,
Baoquan He <baoquan.he@linux.dev>,
Mike Rapoport <rppt@kernel.org>,
kexec@lists.infradead.org,
Andrew Morton <akpm@linux-foundation.org>,
Pasha Tatashin <pasha.tatashin@soleen.com>,
Dave Young <ruirui.yang@linux.dev>,
Alexander Graf <graf@amazon.com>
Subject: Re: RFC: Enable Sashiko code reviews for kexec@lists.infradead.org
Date: Mon, 21 Sep 2026 18:21:26 +0200 [thread overview]
Message-ID: <2vxzse3260e1.fsf@kernel.org> (raw)
In-Reply-To: <C6F5E157-B26C-496D-AF83-B6AA784BC74F@linux.dev> (Roman Gushchin's message of "Wed, 2 Sep 2026 18:02:29 -0700")
On Wed, Sep 02 2026, Roman Gushchin wrote:
>> 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:
[...]
>>> 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?
Sorry for the late reply.
The behaviour is already an option that can be configured
(reply_all=true), I just wasn't aware that was an option. So I don't
think any change is needed.
IMO this should be the default but I can see why you might not want to
do it just yet.
>
>>>
>>> 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.
Yeah, fair enough.
[...]
--
Regards,
Pratyush Yadav
next prev parent reply other threads:[~2026-09-21 16:21 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-01 20:27 RFC: Enable Sashiko code reviews for kexec@lists.infradead.org David Matlack
2026-09-02 4:34 ` Mike Rapoport
2026-09-02 5:52 ` Baoquan He
2026-09-02 8:04 ` Mike Rapoport
2026-09-02 8:25 ` Baoquan He
2026-09-02 9:18 ` Pratyush Yadav
2026-09-02 9:53 ` Baoquan He
2026-09-02 17:58 ` David Matlack
2026-09-03 1:02 ` Roman Gushchin
2026-09-04 21:21 ` David Matlack
2026-09-21 16:21 ` Pratyush Yadav [this message]
2026-09-02 16:29 ` David Matlack
2026-09-02 17:26 ` Mike Rapoport
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2vxzse3260e1.fsf@kernel.org \
--to=pratyush@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=baoquan.he@linux.dev \
--cc=dmatlack@google.com \
--cc=graf@amazon.com \
--cc=kexec@lists.infradead.org \
--cc=pasha.tatashin@soleen.com \
--cc=roman.gushchin@linux.dev \
--cc=rppt@kernel.org \
--cc=ruirui.yang@linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.