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. "D:" should help maintainers reduce
noise in their inboxes, especially when matching omnipresent
keywords like [1]. In the event of [1] 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.
Joe mentioned in v1 that perhaps K: should be reworked to only consider
patch files. I wonder, though, if folks are intentionally using the
current behavior of K: and thus would be peeved from a change there. I
see this series as, at the very least, a gentle migration in behavior
which is purely opt-in and at some point could eagerly be merged with
K:.
[1]: https://lore.kernel.org/all/[email protected]/
Signed-off-by: Justin Stitt <[email protected]>
---
Changes in v2:
- remove bits about non-patch usage being bad (thanks Greg, Kees, et al.)
- remove formatting pass (thanks Joe) (but seriously the formatting is
bad, is there opportunity to get a formatting pass in here at some
point?)
- add some migration from K to D (thanks Kees, Nick)
- Link to v1: https://lore.kernel.org/r/[email protected]
---
Justin Stitt (2):
get_maintainer: add patch-only keyword-matching
MAINTAINERS: migrate some K to D
MAINTAINERS | 21 ++++++++++++++-------
scripts/get_maintainer.pl | 12 ++++++++++--
2 files changed, 24 insertions(+), 9 deletions(-)
---
base-commit: 6465e260f48790807eef06b583b38ca9789b6072
change-id: 20230926-get_maintainer_add_d-07424a814e72
Best regards,
--
Justin Stitt <[email protected]>
On Fri, 2023-09-29 at 11:07 +0900, Justin Stitt wrote:
> On Fri, Sep 29, 2023 at 12:52 AM Nick Desaulniers
> <[email protected]> wrote:
> >
> > On Wed, Sep 27, 2023 at 11:09 PM Joe Perches <[email protected]> wrote:
> > >
> > > On Thu, 2023-09-28 at 14:31 +0900, Justin Stitt wrote:
> > > > On Thu, Sep 28, 2023 at 2:01 PM Joe Perches <[email protected]> wrote:
> > > > >
> > > > > On Thu, 2023-09-28 at 04:23 +0000, Justin Stitt wrote:
> > > > > > Changes in v2:
> > > > > > - remove formatting pass (thanks Joe) (but seriously the formatting is
> > > > > > bad, is there opportunity to get a formatting pass in here at some
> > > > > > point?)
> > > > >
LG G7 Battery Replacement | Guide | Is it actually a Samsung? I t
> > > > > Why? What is it that makes you believe the formatting is bad?
> > > > >
> > > >
> > > > Investigating further, it looked especially bad in my editor. There is
> > > > a mixture of
> > > > tabs and spaces and my vim tabstop is set to 4 for pl files. Setting this to
> > > > 8 is a whole lot better. But I still see some weird spacing
> > > >
> > >
> > > Yes, it's a bit odd indentation.
> > > It's emacs default perl format.
> > > 4 space indent with 8 space tabs, maximal tab fill.
> > >
> >
> > Oh! What?! That's the most surprising convention I've ever heard of
> > (after the GNU C coding style). Yet another thing to hold against
> > perl I guess. :P
> >
> > I have my editor setup to highlight tabs vs spaces via visual cues, so
> > that I don't mess up kernel coding style. (`git clang-format HEAD~`
> > after a commit helps). scripts/get_maintainer.pl has some serious
> > inconsistencies to the point where I'm not sure what it should or was
> > meant to be. Now that you mention it, I see it, and it does seem
> > consistent in that regard.
> >
> > Justin, is your formatter configurable to match that convention?
> > Maybe it's still useful, as long as you configure it to stick to the
> > pre-existing convention.
>
> Negative, all the perl formatters I've tried will convert everything to spaces.
> The best I've seen is perltidy.
>
> https://gist.github.com/JustinStitt/347385921c80a5212c2672075aa769b6
emacs with cperl mode works fine.
I don't know much about vim, but when I open this file in vim
it looks perfectly normal and it's apparently properly syntax
highlighted.
On Fri, Sep 29, 2023 at 12:52 AM Nick Desaulniers
<[email protected]> wrote:
>
> On Wed, Sep 27, 2023 at 11:09 PM Joe Perches <[email protected]> wrote:
> >
> > On Thu, 2023-09-28 at 14:31 +0900, Justin Stitt wrote:
> > > On Thu, Sep 28, 2023 at 2:01 PM Joe Perches <[email protected]> wrote:
> > > >
> > > > On Thu, 2023-09-28 at 04:23 +0000, Justin Stitt wrote:
> > > > > Changes in v2:
> > > > > - remove formatting pass (thanks Joe) (but seriously the formatting is
> > > > > bad, is there opportunity to get a formatting pass in here at some
> > > > > point?)
> > > >
> > > > Why? What is it that makes you believe the formatting is bad?
> > > >
> > >
> > > Investigating further, it looked especially bad in my editor. There is
> > > a mixture of
> > > tabs and spaces and my vim tabstop is set to 4 for pl files. Setting this to
> > > 8 is a whole lot better. But I still see some weird spacing
> > >
> >
> > Yes, it's a bit odd indentation.
> > It's emacs default perl format.
> > 4 space indent with 8 space tabs, maximal tab fill.
> >
>
> Oh! What?! That's the most surprising convention I've ever heard of
> (after the GNU C coding style). Yet another thing to hold against
> perl I guess. :P
>
> I have my editor setup to highlight tabs vs spaces via visual cues, so
> that I don't mess up kernel coding style. (`git clang-format HEAD~`
> after a commit helps). scripts/get_maintainer.pl has some serious
> inconsistencies to the point where I'm not sure what it should or was
> meant to be. Now that you mention it, I see it, and it does seem
> consistent in that regard.
>
> Justin, is your formatter configurable to match that convention?
> Maybe it's still useful, as long as you configure it to stick to the
> pre-existing convention.
Negative, all the perl formatters I've tried will convert everything to spaces.
The best I've seen is perltidy.
https://gist.github.com/JustinStitt/347385921c80a5212c2672075aa769b6
> --
> Thanks,
> ~Nick Desaulniers
On Fri, Sep 29, 2023 at 11:50 AM Joe Perches <[email protected]> wrote:
>
> On Fri, 2023-09-29 at 11:07 +0900, Justin Stitt wrote:
> > On Fri, Sep 29, 2023 at 12:52 AM Nick Desaulniers
> > <[email protected]> wrote:
> > >
> > > On Wed, Sep 27, 2023 at 11:09 PM Joe Perches <[email protected]> wrote:
> > > >
> > > > On Thu, 2023-09-28 at 14:31 +0900, Justin Stitt wrote:
> > > > > On Thu, Sep 28, 2023 at 2:01 PM Joe Perches <[email protected]> wrote:
> > > > > >
> > > > > > On Thu, 2023-09-28 at 04:23 +0000, Justin Stitt wrote:
> > > > > > > Changes in v2:
> > > > > > > - remove formatting pass (thanks Joe) (but seriously the formatting is
> > > > > > > bad, is there opportunity to get a formatting pass in here at some
> > > > > > > point?)
> > > > > >
>
> LG G7 Battery Replacement | Guide | Is it actually a Samsung? I t
> > > > > > Why? What is it that makes you believe the formatting is bad?
> > > > > >
> > > > >
> > > > > Investigating further, it looked especially bad in my editor. There is
> > > > > a mixture of
> > > > > tabs and spaces and my vim tabstop is set to 4 for pl files. Setting this to
> > > > > 8 is a whole lot better. But I still see some weird spacing
> > > > >
> > > >
> > > > Yes, it's a bit odd indentation.
> > > > It's emacs default perl format.
> > > > 4 space indent with 8 space tabs, maximal tab fill.
> > > >
> > >
> > > Oh! What?! That's the most surprising convention I've ever heard of
> > > (after the GNU C coding style). Yet another thing to hold against
> > > perl I guess. :P
> > >
> > > I have my editor setup to highlight tabs vs spaces via visual cues, so
> > > that I don't mess up kernel coding style. (`git clang-format HEAD~`
> > > after a commit helps). scripts/get_maintainer.pl has some serious
> > > inconsistencies to the point where I'm not sure what it should or was
> > > meant to be. Now that you mention it, I see it, and it does seem
> > > consistent in that regard.
> > >
> > > Justin, is your formatter configurable to match that convention?
> > > Maybe it's still useful, as long as you configure it to stick to the
> > > pre-existing convention.
> >
> > Negative, all the perl formatters I've tried will convert everything to spaces.
> > The best I've seen is perltidy.
> >
> > https://gist.github.com/JustinStitt/347385921c80a5212c2672075aa769b6
>
> emacs with cperl mode works fine.
>
> I don't know much about vim, but when I open this file in vim
> it looks perfectly normal and it's apparently properly syntax
> highlighted.
>
I believe a :set tabstop=2 will make it look weird. But really,
this whole formatting thing is a non-issue for me personally
once I discovered what the problem was. I'm not sure this
file attracts nearly enough eyes to warrant an eager
formatting attempt as I was previously preaching for.
Nick and I using vim with special tab handling are most definitely
the exception and for most folks this file probably looks fine.