On Fri, Aug 21, 2020 at 11:05 AM Joe Perches <j...@perches.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.w...@hpe.com> wrote: > > > > > > Signed-off-by: Steve Wahl <steve.w...@hpe.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+hua...@kernel.org> > > (commit_signer:127/806=16%,authored:80/806=10%) > > Rob Herring <r...@kernel.org> (commit_signer:103/806=13%) > > "David S. Miller" <da...@davemloft.net> (commit_signer:99/806=12%) > > linux-kernel@vger.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...@kernel.org> (maintainer:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS) devicet...@vger.kernel.org (open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS) linux-kernel@vger.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
