Sashiko email policy precedence

Sashiko email policy precedence

[Danilo Krummrich]

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 another
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 honored
regardless).

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

For nova-gpu that means that the only way currently to get the reply_all policy
would be to never Cc the rust-for-linux list (which only sets reply_to_author)
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_all) or
less (no reply_to_author).

Given that the rust-for-linux list is like the lkml, I think we should special
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=nova-gpu, but I'd still prefer to be able to get reply_all without dropping
the rust-for-linux list.

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

E.g. when 'passive=true' 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=false) on the non-passive one.

- Danilo

Re: Sashiko email policy precedence

[Miguel Ojeda]

On Mon, Jun 1, 2026 at 1:17 AM Danilo Krummrich <dakr@kernel.org> wrote:
>
> E.g. when 'passive=true' 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=false) on the non-passive one.

The configuration I added didn't explicitly ask for `reply_all =
false` (just `reply_to_author = true`), i.e. perhaps the fact that
something is not set could be used as a "don't care" (e.g. latter
lists could override that).

Special casing "wide lists" sounds also fine.

Roman: on my side, the intention with `reply_to_author` was to make
people aware of Sashiko and hopefully be a good middle-ground default,
not to force something on everyone else.

We could also consider setting `reply_all = true` for rust-for-linux
-- IIUC, from what Danilo says, the current algorithm's conservative
approach would remove that setting as soon as the patch is sent to any
list where that isn't the case, right? Some people would find that
useful (a few even reply directly to the LLM's feedback), but of
course it could be seen as too annoying for others (e.g. readers
subscribing the mailing list that do not want to get bombarded with
even more emails), so that is why I took the other option, but if it
is too complex to implement other logic, I guess it is an option.

Cheers,
Miguel

Re: Sashiko email policy precedence

[Danilo Krummrich]

On Mon Jun 1, 2026 at 8:16 AM CEST, Miguel Ojeda wrote:
> On Mon, Jun 1, 2026 at 1:17 AM Danilo Krummrich <dakr@kernel.org> wrote:
> IIUC, from what Danilo says, the current algorithm's conservative approach
> would remove that setting as soon as the patch is sent to any list where that
> isn't the case, right?

Only if the other list has a sashiko email policy entry in the first place,
otherwise it is not part of the matching loop and no further logic is applied.

I'd assume that this is intentional, and can be read as "no entry, no expressed
preference".

> if it is too complex to implement other logic, I guess it is an option.

Flagging something as wide list seems rather simple [1], the tristate [2] would
work as well, but seems a bit more complicated and potentially requires
adjusting the existing policies.

(Test adjustments stripped from [2]; code is LLM generated.)

[1]

diff --git a/src/email_policy.rs b/src/email_policy.rs
index 9fe1179330f3..1ae892e67535 100644
--- a/src/email_policy.rs
+++ b/src/email_policy.rs
@@ -43,6 +43,10 @@ pub struct SubsystemPolicy {
     pub embargo_hours: Option<u32>,
     #[serde(default)]
     pub send_positive_review: bool,
+    /// When true and co-matched with a non-wide list, only `cc` is
+    /// contributed. All boolean flags are deferred to the non-wide lists.
+    #[serde(default)]
+    pub wide_list: bool,
 }

 impl EmailPolicyConfig {
diff --git a/src/email_router.rs b/src/email_router.rs
index c17273aad8ff..216a85d7738d 100644
--- a/src/email_router.rs
+++ b/src/email_router.rs
@@ -93,7 +93,18 @@ impl EmailRouter {
         let mut send_positive_review = false;
         let mut cc = Vec::new();

-        for p in active_policies {
+        let has_non_wide = active_policies.iter().any(|p| !p.wide_list);
+
+        for p in &active_policies {
+            let deferred = p.wide_list && has_non_wide;
+
+            if deferred {
+                for cr in &p.cc {
+                    cc.push(cr.clone());
+                }
+                continue;
+            }
+
             if p.mute_all {
                 mute_all = true;
             }

[2]

diff --git a/src/email_policy.rs b/src/email_policy.rs
index 9fe1179330f3..5c9d94a4d416 100644
--- a/src/email_policy.rs
+++ b/src/email_policy.rs
@@ -23,14 +23,15 @@ pub struct EmailPolicyConfig {
 pub struct SubsystemPolicy {
     #[serde(default)]
     pub lists: Vec<String>,
+    /// None = no preference, Some(false) = private, Some(true) = public.
     #[serde(default)]
-    pub reply_all: bool,
+    pub reply_all: Option<bool>,
     #[serde(default)]
-    pub reply_to_author: bool,
+    pub reply_to_author: Option<bool>,
     #[serde(default)]
-    pub cc_individuals: bool,
+    pub cc_individuals: Option<bool>,
     #[serde(default)]
-    pub mute_all: bool,
+    pub mute_all: Option<bool>,
     #[serde(default)]
     pub cc: Vec<String>,
     #[serde(default)]
@@ -42,7 +43,7 @@ pub struct SubsystemPolicy {
     #[serde(default)]
     pub embargo_hours: Option<u32>,
     #[serde(default)]
-    pub send_positive_review: bool,
+    pub send_positive_review: Option<bool>,
 }
 
 impl EmailPolicyConfig {
diff --git a/src/email_router.rs b/src/email_router.rs
index c17273aad8ff..452c09411552 100644
--- a/src/email_router.rs
+++ b/src/email_router.rs
@@ -12,6 +12,19 @@ pub enum Action {
 
 pub struct EmailRouter {}
 
+/// Merges two Option<bool> policy votes. `dominant` is the value that wins on
+/// conflict: `true` for mute_all, reply_to_author, cc_individuals, and
+/// send_positive_review (any-true wins); `false` for reply_all (any-false wins).
+fn merge_flag(acc: Option<bool>, vote: Option<bool>, dominant: bool) -> Option<bool> {
+    match (acc, vote) {
+        (_, None) => acc,
+        (None, _) => vote,
+        (Some(v), _) if v == dominant => acc,
+        (_, Some(v)) if v == dominant => vote,
+        _ => acc,
+    }
+}
+
 impl EmailRouter {
     pub fn resolve_patchwork(
         policy: &EmailPolicyConfig,
@@ -86,34 +99,30 @@ impl EmailRouter {
             active_policies.push(&policy.defaults);
         }
 
-        let mut mute_all = false;
-        let mut is_private = false;
-        let mut reply_to_author = false;
-        let mut cc_individuals = false;
-        let mut send_positive_review = false;
+        let mut mute_all = None;
+        let mut reply_all = None;
+        let mut reply_to_author = None;
+        let mut cc_individuals = None;
+        let mut send_positive_review = None;
         let mut cc = Vec::new();
 
         for p in active_policies {
-            if p.mute_all {
-                mute_all = true;
-            }
-            if !p.reply_all {
-                is_private = true;
-            }
-            if p.reply_to_author {
-                reply_to_author = true;
-            }
-            if p.cc_individuals {
-                cc_individuals = true;
-            }
-            if p.send_positive_review {
-                send_positive_review = true;
-            }
+            mute_all = merge_flag(mute_all, p.mute_all, true);
+            reply_all = merge_flag(reply_all, p.reply_all, false);
+            reply_to_author = merge_flag(reply_to_author, p.reply_to_author, true);
+            cc_individuals = merge_flag(cc_individuals, p.cc_individuals, true);
+            send_positive_review = merge_flag(send_positive_review, p.send_positive_review, true);
             for cr in &p.cc {
                 cc.push(cr.clone());
             }
         }
 
+        let mute_all = mute_all.unwrap_or(false);
+        let is_private = !reply_all.unwrap_or(false);
+        let reply_to_author = reply_to_author.unwrap_or(false);
+        let cc_individuals = cc_individuals.unwrap_or(false);
+        let send_positive_review = send_positive_review.unwrap_or(false);
+
         // Always append defaults.cc so users can define a global CC
         for cr in &policy.defaults.cc {
             cc.push(cr.clone());

Re: Sashiko email policy precedence

[Danilo Krummrich]

On Mon Jun 1, 2026 at 11:46 AM CEST, Danilo Krummrich wrote:
> Flagging something as wide list seems rather simple [1], the tristate [2] would
> work as well, but seems a bit more complicated and potentially requires
> adjusting the existing policies.

Roman, any preference on either of those or something else?

Thanks,
Danilo

Re: Sashiko email policy precedence

[Roman Gushchin]

"Danilo Krummrich" <dakr@kernel.org> writes:

> On Mon Jun 1, 2026 at 11:46 AM CEST, Danilo Krummrich wrote:
>> Flagging something as wide list seems rather simple [1], the tristate [2] would
>> work as well, but seems a bit more complicated and potentially requires
>> adjusting the existing policies.
>
> Roman, any preference on either of those or something else?

Sorry for being late to the party.

Yeah, the tricky balance here is that there are people who want more
sashiko reviews and there are people who are quite vocal against it.

And I don't want to over-complicate the setup, I'm afraid it will be
just a constant source of disagreement.

One option, is to switch from mailing list granularity to the
MAINTAINERS-entry granularity. Wdyt?

I don't think I have a perfect model in my head which will cover all
edge cases, tbh. I personally think that reply_to_author + cc the main
mailing list should work pretty much everywhere, but it looks like there
are other opinions as well.

Thanks

Re: Sashiko email policy precedence

[Miguel Ojeda]

On Tue, Jun 9, 2026 at 6:27 PM Roman Gushchin <roman.gushchin@linux.dev> wrote:
>
> One option, is to switch from mailing list granularity to the
> MAINTAINERS-entry granularity. Wdyt?

Hmm... What does this mean / how would it work?

Cheers,
Miguel

Re: Sashiko email policy precedence

[Roman Gushchin]

Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> writes:

> On Tue, Jun 9, 2026 at 6:27 PM Roman Gushchin <roman.gushchin@linux.dev> wrote:
>>
>> One option, is to switch from mailing list granularity to the
>> MAINTAINERS-entry granularity. Wdyt?
>
> Hmm... What does this mean / how would it work?

Very vague idea at this point, but: for each patchset sashiko can
determine the main MAINTAINERS entry it covers and apply it's rules.
That would help with the case when large mailing lists are cc'ed.
Now if e.g. a patchset is sent to e.g. bpf@ and netdev@, sashiko
tries to find a combination of the rules and it's kinda tricky...
Maybe the better approach is to decide which subsystem is primary here,
e.g. by the subject prefix or diff stat, and go with the corresponding
rules.

Thanks,
Roman

Re: Sashiko email policy precedence

[Danilo Krummrich]

On Tue Jun 9, 2026 at 6:26 PM CEST, Roman Gushchin wrote:
> "Danilo Krummrich" <dakr@kernel.org> writes:
>
>> On Mon Jun 1, 2026 at 11:46 AM CEST, Danilo Krummrich wrote:
>>> Flagging something as wide list seems rather simple [1], the tristate [2] would
>>> work as well, but seems a bit more complicated and potentially requires
>>> adjusting the existing policies.
>>
>> Roman, any preference on either of those or something else?
>
> Sorry for being late to the party.

No worries, and thanks for catching up.

> Yeah, the tricky balance here is that there are people who want more
> sashiko reviews and there are people who are quite vocal against it.
>
> And I don't want to over-complicate the setup, I'm afraid it will be
> just a constant source of disagreement.

I think it usually works out well as is if multiple subsystems are involved.

The only case where it falls apart is with wide lists potentially spanning all
subsystems with a certain policy, which if handled like any other list, may end
up taking precedence over all subsystem lists regardless of their preference.

Hence the proposal to just special case wide lists, so they can't take
precedence over everything.

> One option, is to switch from mailing list granularity to the
> MAINTAINERS-entry granularity. Wdyt?

As mentioned above, I think the main issue are wide lists, and switching to a
MAINTAINERS-entry granularity wouldn't cover that (unless I am missing
something).

> I don't think I have a perfect model in my head which will cover all edge
> cases, tbh.

The wide list case is not an edge case.

Taking the R4L list aside, if we would set reply_to_author for the LKML, which
does not seem entirely unreasonable, it would have the same effect, which is no
one's reply_all setting would be honored anymore.

> I personally think that reply_to_author + cc the main mailing list should work
> pretty much everywhere, but it looks like there are other opinions as well.

It can be quite cumbersome when people pick up a discussion based on a point
made by Sashiko and some people are excluded from the discussion because only
the mailing list and specific people are statically Cc'd.

People that were Cc'd explicitly on a patch series usually don't expect to have
to switch to the mailing list to capture every discussion.