[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <8213206d4764375f32cbea36ea214573248094dc.camel@perches.com>
Date: Fri, 21 Aug 2020 10:05:16 -0700
From: Joe Perches <joe@...ches.com>
To: Rob Herring <robh@...nel.org>, Steve Wahl <steve.wahl@....com>
Cc: Mauro Carvalho Chehab <mchehab+huawei@...nel.org>,
"David S. Miller" <davem@...emloft.net>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Dimitri Sivanich <dimitri.sivanich@....com>,
Russ Anderson <russ.anderson@....com>
Subject: Re: [PATCH] MAINTAINERS: Add entry for HPE Superdome Flex (UV)
maintainers
On Fri, 2020-08-21 at 10:45 -0600, Rob Herring wrote:
> +Joe Perches
>
> On Fri, Aug 21, 2020 at 9:48 AM Steve Wahl <steve.wahl@....com> wrote:
> >
> > Signed-off-by: Steve Wahl <steve.wahl@....com>
>
> get_maintainers.pl doesn't work on MAINTAINERS. You need to send this
> to the maintainers of the files listed in the entry below. Looks like
> that would be the x86 maintainers.
>
>
> What did Mauro, David and I do to become MAINTAINERS maintainers?
>
> Mauro Carvalho Chehab <mchehab+huawei@...nel.org>
> (commit_signer:127/806=16%,authored:80/806=10%)
> Rob Herring <robh@...nel.org> (commit_signer:103/806=13%)
> "David S. Miller" <davem@...emloft.net> (commit_signer:99/806=12%)
> linux-kernel@...r.kernel.org (open list)
>
>
> Can we make --no-git-fallback the default? It's useful for
> informational purposes, but never for who to email patches to. Having
> no output would be better, then submitters have to think about where
> to send patches.
Doubtful that improves things. At least the --git-fallback option
shows who modified or got patches accepted to files that are
nominally unmaintained. It also shows the upstream path for those
files via Signed-off-by: lines so I think --git-fallback is generally
a good mechanism and control flag for directly unmaintained files.
> What ever happened to splitting up MAINTAINERS to subdirectories? That
> would help routing MAINTAINERS changes to the right maintainers.
Splitting MAINTAINERS into subdirectories would do nothing
to route patches. It would just be convenience to reduce
the total number of changes to a single file.
Those large number of changes to the single MAINTAINERS file
very rarely have any conflicts either, so it wouldn't really
change the overall number of changes to MAINTAINERS entries
spread around the tree.
You are be welcome to try to split the file and get Linus to
accept it. I gave it a go. Try yourself.
https://lore.kernel.org/patchwork/patch/817857/
Powered by blists - more mailing lists