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