On Wed, Sep 27, 2023 at 08:24:58AM -0700, Nick Desaulniers wrote: > On Tue, Sep 26, 2023 at 8:19 PM Justin Stitt <justinstitt@xxxxxxxxxx> wrote: > > > > This series aims to add "D:" which behaves exactly the same as "K:" but > > works only on patch files. > > > > The goal of this is to reduce noise when folks use get_maintainer on > > tree files as opposed to patches. This use case should be steered away > > from [1] but "D:" should help maintainers reduce noise in their inboxes > > regardless, especially when matching omnipresent keywords like [2]. In > > the event of [2] Kees would be to/cc'd from folks running get_maintainer > > on _any_ file containing "__counted_by". The number of these files is > > rising and I fear for his inbox as his goal, as I understand it, is to > > simply monitor the introduction of new __counted_by annotations to > > ensure accurate semantics. > > Something like this (whether this series or a different approach) > would be helpful to me as well; we use K: to get cc'ed on patches > mentioning clang or llvm, but our ML also then ends up getting cc'ed > on every follow up patch to most files. > > This is causing excessive posts on our ML. As a result, it's a > struggle to get folks to cc themselves to the ML, which puts the code > review burden on fewer people. > > Whether it's a new D: or refinement to the behavior of K:, I applaud > the effort. Hopefully we can find an approach that works for > everyone. Yes, please! I would use this immediately -- there are a bunch of places where pstore, strings, hardening, etc all want review if certain functions or structures are changed in a patch, but we're not maintainers of the files they appear in. > > Justin Stitt (3): > > MAINTAINERS: add documentation for D: > > get_maintainer: add patch-only pattern matching type Can we squash these two changes together, and then likely add some patches for moving things out of K: ? -- Kees Cook
