Re: Stop false review statements

> On May 17, 2026, at 8:56=E2=80=AFAM, Danilo Krummrich <[email protected]> wr=
ote:
>=20
> =EF=BB=BFOn Sat May 16, 2026 at 9:15 PM CEST, Roman Gushchin wrote:
>> I agree, it=E2=80=99s sometimes gets tricky when a patchset is sent to mu=
ltiple
>> mailing lists, which policy to apply. I have some improvements in my plan=
s,
>> but it=E2=80=99s not always possible to say how it should be handled.
>=20
> Which improvements do you have in mind?

If a patchset is sent to multiple mailing lists now Sashiko is using the sup=
erset of
email policies. But in many cases it=E2=80=99s possible to determine the =E2=
=80=9Cmain=E2=80=9D mailing list/subsystem
and prefer it=E2=80=99s configuration. Not always.

>=20
>> It=E2=80=99s not fundamentally new: landing changes touching multiple sub=
systems is
>> always harder exactly because maintainers might have different and someti=
mes
>> conflicting views.
>=20
> It can also be relevant in cases where only a single subsystem is touched.=

>=20
> For instance, in the case of Rust, the rust-for-linux list serves two purp=
oses
> -- when it is a Rust subsystem change and when Rust code of any other subs=
ystem
> is touched, i.e. the rust-for-linux list has more of a LKML character and a=
lso
> receives patches for subsystems whose maintainers may not have opted in to=

> sashiko email delivery.
>=20
> That said, I personally don't mind too much, I really like sashiko, which i=
s
> also why I asked for adding the driver-core list. My experience has been t=
hat it
> does a very decent job in providing feedback for C code; my feeling is tha=
t
> feedback for Rust code is not quite on par yet, but of course it also high=
ly
> depends on the complexity and scope of the corresponding changes.

This is super interesting. An obvious idea is that the training set is relat=
ively limited,
if we=E2=80=99re talking rust for kernel code. Did you notice any common top=
ics or patterns?
Does it produce more false positives or worse in finding actual bugs in comp=
arison
to the c code?

> However, I still have the same concern I raised previously when it comes t=
o
> email delivery: I think that when sashiko sends feedback to contributors
> (without Cc'ing the mailing list and all other recipients), it should acti=
vely
> ask the contributor to raise things on the list with all other recipients,=

> reviewers and maintainers before acting on them, such that changes subsequ=
ent to
> the first submission on the list are aligned.

I personally think that it=E2=80=99s always better to cc some mailing list a=
nd/or maintainers,
so there is a second pair of eyes. I totally agree that replying just to the=
 author is less effective.
Of course, we can add the text you=E2=80=99re proposing, but why not simply c=
onfigure sashiko=20
to cc the mailing list?

Thanks!=