Re: [PATCH] get_maintainer: add support for using an alternate MAINTAINERS file

[Joe Perches <joe@perches.com>]

On Fri, 2015-10-16 at 21:35 +0300, Jani Nikula wrote:
> On Fri, 16 Oct 2015, Joe Perches <joe@perches.com> wrote:
> > On Fri, 2015-10-16 at 12:14 +0300, Jani Nikula wrote:
> >> On Fri, 16 Oct 2015, Joe Perches <joe@perches.com> wrote:
> >> > On Fri, 2015-10-16 at 11:36 +0300, Jani Nikula wrote:
> >> >> There are large and/or complex subsystems/drivers that have domain
> >> >> experts that should review patches in their domain. One such example is
> >> >> drm/i915. We'd like to be able to document this in a way that can be
> >> >> automatically queried for each patch, so people know who to ping for
> >> >> reviews. This is what get_maintainer.pl already solves.
> >> >> 
> >> >> However, documenting all of this in the main kernel MAINTAINERS file is
> >> >> just too much noise, and potentially confusing for community
> >> >> contributors. Add support for specifying and using an alternate
> >> >> MAINTAINERS file with --maintainers option.
> >> >
> >> > Is this really useful for the community at large?
> >> 
> >> Probably not.
> >> 
> >> > This seems like something that might be useful for an
> >> > organization but not others.
> >> 
> >> It may be useful for several organizations contributing to the kernel.
> >> 
> >> > Why is specifying whatever is necessary in the existing
> >> > MAINTAINERS file noisy or confusing?
> >> 
> >> IIUC you can't specify file patterns for specific reviewers within one
> >> entry. I think we'd have to split up the driver entry to several, mostly
> >> duplicated and possibly overlapping entries, with their own designated
> >> reviewers and file patterns. I think that would be noisy and confusing.
> >
> > I find the concept of adding separate MAINTAINERS files odd
> > and at best and not good for the community.
> 
> Let me get this straight. You're rejecting a trivial patch increasing
> the usefulness of a simple script to a number of kernel developers not
> on technical grounds but because in your view the intended use is not
> good for the community?

Yes.

I think it's perfectly fine to keep something like this
out-of-tree in your own repository.

>  So had I said, this patch enables one to write
> unit tests for the script with various input files, the outcome might
> have been different?

No.  Nice try though.