Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Trevor Woerner <trevor.woerner@linaro.org>
To: Otavio Salvador <otavio@ossystems.com.br>
Cc: Patches and discussions about the oe-core layer
	<openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH 1/1] scripts: add get_maintainer script
Date: Sun, 02 Feb 2014 19:51:38 -0500	[thread overview]
Message-ID: <52EEE81A.9080906@linaro.org> (raw)
In-Reply-To: <CAP9ODKrULmq0BdYtPYqug34dReOfqtntFky_W2m4EKjLvVgb4g@mail.gmail.com>

Hi Otavio,

Thanks for taking a look at my patch.

On 02/02/14 19:23, Otavio Salvador wrote:
> I like to idea and I second this pull request, the only thing I would
> like to see added is the possibility of grabing the maintainers for
> boards from the machine .conf file. This is the way we're using at
> meta-fsl-arm and meta-fsl-arm-extra. What do you think? 

To be honest I don't have much experience with perl, this script is in
perl simply because that's the way it comes to us from the Linux kernel
(although I was able to understand enough of it to be able to make the
changes required so it would fit into this project). I'm quite sure,
with StackOverflow by my side, I'd be more than able to make these
changes :-)

However... the MAINTAINERS syntax[1] does allow for "F", "N", "X", and
"K" clauses, to wit:

	F: Files and directories with wildcard patterns.
	   A trailing slash includes all files and subdirectory files.
	   F:	drivers/net/	all files in and below drivers/net
	   F:	drivers/net/*	all files in drivers/net, but not below
	   F:	*/net/*		all files in "any top level directory"/net
	   One pattern per line.  Multiple F: lines acceptable.
	N: Files and directories with regex patterns.
	   N:	[^a-z]tegra	all files whose path contains the word tegra
	   One pattern per line.  Multiple N: lines acceptable.
	   scripts/get_maintainer.pl has different behavior for files that
	   match F: pattern and matches of N: patterns.  By default,
	   get_maintainer will not look at git log history when an F: pattern
	   match occurs.  When an N: match occurs, git log history is used
	   to also notify the people that have git commit signatures.
	X: Files and directories that are NOT maintained, same rules as F:
	   Files exclusions are tested before file matches.
	   Can be useful for excluding a specific subdirectory, for instance:
	   F:	net/
	   X:	net/ipv6/
	   matches all files in and below net excluding net/ipv6/
	K: Keyword perl extended regex pattern to match content in a
	   patch or file.  For instance:
	   K: of_get_profile
	      matches patches or files that contain "of_get_profile"
	   K: \b(printk|pr_(info|err))\b
	      matches patches or files that contain one or more of the words
	      printk, pr_info or pr_err
	   One regex pattern per line.  Multiple K: lines acceptable.


As you can see, use of these clauses would cover your use case.

What I was hoping for is that this script would be added to the project,
then I could go about creating MAINTAINERS files for the various layers
which would incorporate the information to which you referred above in a
more standard, cross-project way. If you feel strongly about keeping the
maintainers information in these files and this is the only thing
holding up the script's inclusion I'd be happy to make the necessary
modifications. But personally I'd prefer to use the existing MAINTAINERS
syntax instead.

Would moving that information into a standard top-level MAINTAINERS file
suffice? Is there a reason it needs to be in those files (perhaps some
other tool is processing them that couldn't be switched to process a
MAINTAINERS file instead)?

Best regards,
    Trevor


[1] https://www.kernel.org/doc/linux/MAINTAINERS


      reply	other threads:[~2014-02-03  0:51 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-31 22:47 [PATCH 0/1] scripts: add get_maintainer script Trevor Woerner
2014-01-31 22:47 ` [PATCH 1/1] " Trevor Woerner
2014-02-03  0:23   ` Otavio Salvador
2014-02-03  0:51     ` Trevor Woerner [this message]

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=52EEE81A.9080906@linaro.org \
    --to=trevor.woerner@linaro.org \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=otavio@ossystems.com.br \
    /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