[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAL_JsqL0v6PXgMLVZzqZwjpZ4KTUGmutg6Z0YuvTccdAUa-=mw@mail.gmail.com>
Date: Fri, 21 Aug 2020 12:17:57 -0600
From: Rob Herring <robh@...nel.org>
To: Joe Perches <joe@...ches.com>
Cc: Steve Wahl <steve.wahl@....com>,
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, Aug 21, 2020 at 11:05 AM Joe Perches <joe@...ches.com> 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@....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.
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@...nel.org> (maintainer:OPEN FIRMWARE AND
FLATTENED DEVICE TREE BINDINGS)
devicetree@...r.kernel.org (open list:OPEN FIRMWARE AND FLATTENED
DEVICE TREE BINDINGS)
linux-kernel@...r.kernel.org (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
Powered by blists - more mailing lists