> On May 17, 2026, at 8:56 AM, Danilo Krummrich <[email protected]> wrote: > > On Sat May 16, 2026 at 9:15 PM CEST, Roman Gushchin wrote: >> I agree, it’s sometimes gets tricky when a patchset is sent to multiple >> mailing lists, which policy to apply. I have some improvements in my plans, >> but it’s not always possible to say how it should be handled. > > Which improvements do you have in mind?
If a patchset is sent to multiple mailing lists now Sashiko is using the superset of email policies. But in many cases it’s possible to determine the “main” mailing list/subsystem and prefer it’s configuration. Not always. > >> It’s not fundamentally new: landing changes touching multiple subsystems is >> always harder exactly because maintainers might have different and sometimes >> conflicting views. > > It can also be relevant in cases where only a single subsystem is touched. > > For instance, in the case of Rust, the rust-for-linux list serves two purposes > -- when it is a Rust subsystem change and when Rust code of any other > subsystem > is touched, i.e. the rust-for-linux list has more of a LKML character and also > receives patches for subsystems whose maintainers may not have opted in to > sashiko email delivery. > > That said, I personally don't mind too much, I really like sashiko, which is > also why I asked for adding the driver-core list. My experience has been that > it > does a very decent job in providing feedback for C code; my feeling is that > feedback for Rust code is not quite on par yet, but of course it also highly > depends on the complexity and scope of the corresponding changes. This is super interesting. An obvious idea is that the training set is relatively limited, if we’re talking rust for kernel code. Did you notice any common topics or patterns? Does it produce more false positives or worse in finding actual bugs in comparison to the c code? > However, I still have the same concern I raised previously when it comes to > email delivery: I think that when sashiko sends feedback to contributors > (without Cc'ing the mailing list and all other recipients), it should actively > ask the contributor to raise things on the list with all other recipients, > reviewers and maintainers before acting on them, such that changes subsequent > to > the first submission on the list are aligned. I personally think that it’s always better to cc some mailing list and/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’re proposing, but why not simply configure sashiko to cc the mailing list? Thanks!
