public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Joe Perches <joe@perches.com>
To: Jani Nikula <jani.nikula@intel.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] get_maintainer: add support for using an alternate MAINTAINERS file
Date: Fri, 16 Oct 2015 09:23:54 -0700	[thread overview]
Message-ID: <1445012634.22921.34.camel@perches.com> (raw)
In-Reply-To: <878u73npjg.fsf@intel.com>

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.

Internal to an organization, if this is for subject matter
expert reviewers, perhaps it'd be better to add an optional
"REVIEWERS" file (or maybe multiple REVIEWER.* files) with
simpler patterns.

Using just R: F: X: N: K: would probably work.

This wouldn't have to be section ordered like MAINTAINERS,
but could also be ordered by reviewer skills.

For example:

$ cat REVIEWERS
BIGCO PHYS
M:	Joe Schmo <joe.schmo@bigco.com>
F:	drivers/net/ethernet/bigco/*/*phy*




  reply	other threads:[~2015-10-16 16:24 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-16  8:36 [PATCH] get_maintainer: add support for using an alternate MAINTAINERS file Jani Nikula
2015-10-16  8:50 ` Joe Perches
2015-10-16  9:14   ` Jani Nikula
2015-10-16 16:23     ` Joe Perches [this message]
2015-10-16 17:37       ` Joe Perches
2015-10-16 18:35       ` Jani Nikula
2015-10-16 18:41         ` Joe Perches
2015-10-16 18:56           ` Jani Nikula

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1445012634.22921.34.camel@perches.com \
    --to=joe@perches.com \
    --cc=jani.nikula@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox