All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joe Perches <joe@perches.com>
To: Justin Stitt <justinstitt@google.com>
Cc: linux-kernel@vger.kernel.org, Kees Cook <keescook@chromium.org>,
	Nick Desaulniers <ndesaulniers@google.com>
Subject: Re: [PATCH] get_maintainer/MAINTAINERS: confine K content matching to patches
Date: Thu, 05 Oct 2023 13:05:53 -0700	[thread overview]
Message-ID: <eea5087a2bd94b80b5a16af95a4caf20376bbc52.camel@perches.com> (raw)
In-Reply-To: <CAFhGd8rGZ6w7bz90LRnwd_1K3ibR2KsT6cJ2kiuO5mSAdnWjFw@mail.gmail.com>

On Thu, 2023-10-05 at 12:52 -0700, Justin Stitt wrote:
> On Thu, Oct 5, 2023 at 11:42 AM Joe Perches <joe@perches.com> wrote:
> > 
> > On Thu, 2023-10-05 at 11:30 -0700, Justin Stitt wrote:
> > > On Thu, Oct 5, 2023 at 11:15 AM Joe Perches <joe@perches.com> wrote:
> > > > 
> > > > On Thu, 2023-10-05 at 11:06 -0700, Justin Stitt wrote:
> > > > > On Wed, Oct 4, 2023 at 7:40 PM Joe Perches <joe@perches.com> wrote:
> > > > > > 
> > > > > > On Wed, 2023-10-04 at 21:21 +0000, Justin Stitt wrote:
> > > > > > > The current behavior of K: is a tad bit noisy. It matches against the
> > > > > > > entire contents of files instead of just against the contents of a
> > > > > > > patch.
> > > > > > > 
> > > > > > > This means that a patch with a single character change (fixing a typo or
> > > > > > > whitespace or something) would still to/cc maintainers and lists if the
> > > > > > > affected file matched against the regex pattern given in K:. For
> > > > > > > example, if a file has the word "clang" in it then every single patch
> > > > > > > touching that file will to/cc Nick, Nathan and some lists.
> > > > > > > 
> > > > > > > Let's change this behavior to only content match against patches
> > > > > > > (subjects, message, diff) as this is what most people expect the
> > > > > > > behavior already is. Most users of "K:" would prefer patch-only content
> > > > > > > matching. If this is not the case let's add a new matching type as
> > > > > > > proposed in [1].
> > > > > > 
> > > > > > I'm glad to know  you are coming around to my suggestion.
> > > > > :)
> > > > > 
> > > > > > 
> > > > > > I believe the file-based keyword matching should _not_ be
> > > > > > removed and the option should be added for it like I suggested.
> > > > > 
> > > > > Having a command line flag allowing get_maintainer.pl
> > > > > users to decide the behavior of K: is weird to me. If I'm a maintainer setting
> > > > > my K: in MAINTAINERS I want some sort of consistent behavior. Some
> > > > > patches will start hitting mailing list that DO have keywords in the patch
> > > > > and others, confusingly, not.
> > > > 
> > > > Not true.
> > > > 
> > > > If a patch contains a keyword match, get_maintainers will _always_
> > > > show the K: keyword maintainers unless --nokeywords is specified
> > > > on the command line.
> > > 
> > > ...
> > > 
> > > > 
> > > > If a file contains a keyword match, it'll only show the K:
> > > > keyword  if --keywords-in-file is set.
> > > 
> > > Right, what I'm saying is a patch can arrive in a maintainer's inbox
> > > wherein the patch itself has no mention of the keyword (if
> > > get_maintainer user opted for --keywords-in-file). Just trying to
> > > avoid some cases of the question: "Why is this in my inbox?"
> > 
> > Because the script user specifically asked for it.
> > 
> > > > > To note, we get some speed-up here as pattern matching a patch that
> > > > > touches lots of files would result in searching all of them in their
> > > > > entirety. Just removing this behavior _might_ have a measurable
> > > > > speed-up for patch series touching dozens of files.
> > > > 
> > > > Again, not true.
> > > > 
> > > > Patches do _not_ scan the original modified files for keyword matches.
> > > > Only the patch itself is scanned.  That's the current behavior as well.
> > > > 
> > > 
> > > Feel like I'm missing something here. How is K: matching keywords in
> > > files without reading them.
> > > 
> > > If my patch touches 10 files then all 10 of those files are scanned for
> > > K: matches right?
> > 
> > Nope.
> > 
> > Understand the patches are the input to get_maintainer and not
> > just files.
> > 
> > If a patch is fed to get_maintainer then any files modified by
> > the patch are _not_ scanned.
> > 
> > Only the patch _content_ is used for keyword matches.
> > 
> 
> Got it. I'll roll your patch into a v3.
> 

Actually, I have a slightly improved patch as
the actual keyword is shown too.

I'll get it uploaded and make sure you are credited
with the effort to make the change.

cheers, Joe

  reply	other threads:[~2023-10-05 20:06 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-04 21:21 [PATCH] get_maintainer/MAINTAINERS: confine K content matching to patches Justin Stitt
2023-10-05  2:40 ` Joe Perches
2023-10-05 18:06   ` Justin Stitt
2023-10-05 18:15     ` Joe Perches
2023-10-05 18:30       ` Justin Stitt
2023-10-05 18:42         ` Joe Perches
2023-10-05 19:52           ` Justin Stitt
2023-10-05 20:05             ` Joe Perches [this message]
2023-10-05 20:10               ` Justin Stitt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=eea5087a2bd94b80b5a16af95a4caf20376bbc52.camel@perches.com \
    --to=joe@perches.com \
    --cc=justinstitt@google.com \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ndesaulniers@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.