Re: [PATCH] MAINTAINERS: Add entry for HPE Superdome Flex (UV) maintainers

[Rob Herring]

On Fri, Aug 21, 2020 at 11:05 AM Joe Perches <joe@xxxxxxxxxxx> wrote:
>
> 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@xxxxxxx> wrote:
> > >
> > > Signed-off-by: Steve Wahl <steve.wahl@xxxxxxx>
> >
> > 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@xxxxxxxxxx>
> > (commit_signer:127/806=16%,authored:80/806=10%)
> > Rob Herring <robh@xxxxxxxxxx> (commit_signer:103/806=13%)
> > "David S. Miller" <davem@xxxxxxxxxxxxx> (commit_signer:99/806=12%)
> > linux-kernel@xxxxxxxxxxxxxxx (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.

In general no, but for MAINTAINERS changes it would. Let's say I add
an entry for Documentation/devicetree/foo-bar.txt. With a per
subsystem/path MAINTAINERS file in
Documentation/devicetree/MAINTAINERS, you'd add an entry there and run
get_maintainer.pl:

$ touch Documentation/devicetree/MAINTAINERS
$ scripts/get_maintainer.pl -f Documentation/devicetree/MAINTAINERS
Rob Herring <robh+dt@xxxxxxxxxx> (maintainer:OPEN FIRMWARE AND
FLATTENED DEVICE TREE BINDINGS)
devicetree@xxxxxxxxxxxxxxx (open list:OPEN FIRMWARE AND FLATTENED
DEVICE TREE BINDINGS)
linux-kernel@xxxxxxxxxxxxxxx (open list)

> 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/

Yes, I remember that. He didn't seem totally opposed to it which is why I asked.

I have another reason for wanting the split. I want to generate a
MAINTAINERS file from the DT schema files. We have the data there and
it's checked automatically. I don't care to either continually tell
folks to add a MAINTAINERS entry or tell them to run checkpatch.pl to
tell them that. But if the infrastructure got merged, would that
already work?

Rob