Sashiko email policy precedence

"Danilo Krummrich" <[email protected]> Mon, 01 Jun 2026 01:17:52 +0200
Newsgroups dev.linux.lists.sashiko
Message-ID <[email protected]>
Hi Roman,

We just enabled nova-gpu with the reply_all email policy and I noticed that
sashiko does not actually send any such replies.

I did dig a bit and it seems that the logic here is that if there is anothe=
r
mailing list Cc'd that is in the sashiko email policy, but does not have
reply_all set, reply_all is removed (while reply_to_author is always honore=
d
regardless).

In contrast, if another list that does not have an email policy at all is C=
c'd,
reply_all is not removed.

For nova-gpu that means that the only way currently to get the reply_all po=
licy
would be to never Cc the rust-for-linux list (which only sets reply_to_auth=
or)
in the first place.

In fact, it seems to boil down to any subsystem list that handles Rust code=
 is
stuck with reply_to_author, regardless whether it wants more (e.g. reply_al=
l) or
less (no reply_to_author).

Given that the rust-for-linux list is like the lkml, I think we should spec=
ial
case it, so it does not mess with the policy from other subsystems too much=
.

One low-hanging fruit to improve this a bit would of course be to add
cc=3Dnova-gpu, but I'd still prefer to be able to get reply_all without dro=
pping
the rust-for-linux list.

Maybe adding a separate flag to be set by "catch all" mailing lists could b=
e an
option?

E.g. when 'passive=3Dtrue' is set and a passive list is matched with a non-=
passive
one the passive one won't impose its restrictive defaults (e.g.
reply_all=3Dfalse) on the non-passive one.

- Danilo