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? > 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. 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. Can this be added please? Thanks, Danilo
