From: "Danilo Krummrich" <dakr@kernel.org>
To: "Roman Gushchin" <roman.gushchin@linux.dev>
Cc: "John Hubbard" <jhubbard@nvidia.com>,
"Miguel Ojeda" <ojeda@kernel.org>,
<rust-for-linux@vger.kernel.org>,
"Alexandre Courbot" <acourbot@nvidia.com>, <lyude@redhat.com>
Subject: Re: Maybe make Sashiko emails opt-in please?
Date: Mon, 27 Apr 2026 01:38:34 +0200 [thread overview]
Message-ID: <DI3HDPG6L4CC.CHUY8XUFNFHG@kernel.org> (raw)
In-Reply-To: <7ia4tst18grc.fsf@castle.c.googlers.com>
On Fri Apr 24, 2026 at 12:16 AM CEST, Roman Gushchin wrote:
> I generally rely on maintainers for the decision how to use Sashiko or not use
> at all.
I think in practice, this doesn't work out. Regardless of how maintainers decide
for their subsystems, once another subsystem mailing list is involved things are
overwritten in one or the other way. This is especially true for mailing lists
such as the rust-for-linux one, which span across various subsystems.
My main concern with the current approach is that I'm worried that contributors
of the subsystems / components / drivers I maintain may immediately act on
feedback without discussing the validity of the feedback or the solution for the
problem with other people on the list first, when it is received as a private
message.
(Analogously, I would not like if for publically posted patches reviewers would
provide private feedback to the contributor.)
That said, I don't know what a solution would look like to actually make this a
maintainer decision; most likely it simply isn't possible and it has to be a
collective decision.
For me personally it would be fine if we could add a clear disclaimer upfront
that mentions that contributors should share when and how they plan to act on
the received feedback with all other recipients of the patch (series) before
acting on it (unless it is obviously trivial).
As for the opt-out, unless sashiko feedback is sent in a way that all recipients
of a patch can discuss it as necessary, any sashiko mails to me go straight into
the bin anyways, as I look things up on the website as necessary.
That said, I really like the tool and I think it provides very valuable feedback
-- thanks for working on this!
- Danilo
prev parent reply other threads:[~2026-04-26 23:38 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-23 1:10 Maybe make Sashiko emails opt-in please? lyude
2026-04-23 1:48 ` Alexandre Courbot
2026-04-23 20:24 ` John Hubbard
2026-04-23 22:16 ` Roman Gushchin
2026-04-24 23:22 ` Miguel Ojeda
2026-04-26 23:38 ` Danilo Krummrich [this message]
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=DI3HDPG6L4CC.CHUY8XUFNFHG@kernel.org \
--to=dakr@kernel.org \
--cc=acourbot@nvidia.com \
--cc=jhubbard@nvidia.com \
--cc=lyude@redhat.com \
--cc=ojeda@kernel.org \
--cc=roman.gushchin@linux.dev \
--cc=rust-for-linux@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox