On 11/04/2016, 11:27 AM, Jiri Slaby wrote:
> My perl v5.24.0 complains when running the get_maintainer.pl script as
> follows:
> Unrecognized character \xA0; marked by <-- HERE after <-- HERE near column 1
> at ./scripts/get_maintainer.pl line 277.
>
> It is weird to have ascii non-breaking space
My perl v5.24.0 complains when running the get_maintainer.pl script as
follows:
Unrecognized character \xA0; marked by <-- HERE after <-- HERE near column 1 at
./scripts/get_maintainer.pl line 277.
It is weird to have ascii non-breaking spaces in a script, so do:
s/\xa0/ /g
Signed-off-by: Jiri S
My perl v5.24.0 complains when running the get_maintainer.pl script as
follows:
Unrecognized character \xA0; marked by <-- HERE after <-- HERE near column 1 at
./scripts/get_maintainer.pl line 277.
It is weird to have ascii non-breaking spaces in a script, so do:
s/\xa0/ /g
Signed-off-by: Jiri S
Use whatever git or hg say is the root of the current repository as
the kernel tree root, falling back to ./ if no VCS is used.
This makes it possible to call get_maintainer.pl from anywhere in the
kernel tree.
Signed-off-by: Frederik Völkel
Signed-off-by: Lukas Braun
---
scripts/get_maintainer
On Fri, Aug 03, 2012 at 05:37:30PM -0700, Joe Perches wrote:
> On Fri, 2012-08-03 at 11:47 -0700, Josh Triplett wrote:
> > On Fri, Aug 03, 2012 at 11:33:21AM -0700, Joe Perches wrote:
> > > On Fri, 2012-08-03 at 11:27 -0700, Josh Triplett wrote:
> > > > scripts/get_maintainer.pl defaults to showing
On Fri, 2012-08-03 at 11:47 -0700, Josh Triplett wrote:
> On Fri, Aug 03, 2012 at 11:33:21AM -0700, Joe Perches wrote:
> > On Fri, 2012-08-03 at 11:27 -0700, Josh Triplett wrote:
> > > scripts/get_maintainer.pl defaults to showing --rolestats, which
> > > provides annotations explaining why each pe
On Fri, Aug 03, 2012 at 11:33:21AM -0700, Joe Perches wrote:
> On Fri, 2012-08-03 at 11:27 -0700, Josh Triplett wrote:
> > scripts/get_maintainer.pl defaults to showing --rolestats, which
> > provides annotations explaining why each person or list might want to
> > know about a patch. This works w
On Fri, 2012-08-03 at 11:27 -0700, Josh Triplett wrote:
> scripts/get_maintainer.pl defaults to showing --rolestats, which
> provides annotations explaining why each person or list might want to
> know about a patch. This works well for interactive use, but breaks
> when used with git send-email's
scripts/get_maintainer.pl defaults to showing --rolestats, which
provides annotations explaining why each person or list might want to
know about a patch. This works well for interactive use, but breaks
when used with git send-email's --to-cmd or --cc-cmd, resulting in
malformed email headers and
Find maintainer info for a patch or a file
Changes since last submission: (in for a penny...)
Might as well do them all.
Added --status - Print the status information
Added --subsystem - Print the subsystem title
Signed-off-by: Joe Perches <[EMAIL PROTECTED]>
diff --git a/scripts/get_maintainer
Find maintainer info for a patch or a file
Changes since last submission:
Added -f to search for the maintainer for a specific file
Added --scm - Print the S: information
Added --web - Print the W: information
Added die message "git not found. Add --nogit to options"
Changed git log tracking in
On 08/16/2007 09:00 PM, Junio C Hamano wrote:
Git or no git, I think a file that can be viewed with less,
edited with regular editor and processed with sed/perl/grep
tools is the way to go. I do not think adding 600+ patches to
the single MAINTAINERS list is workable in the longer term, as
it w
On Thu, 2007-08-16 at 19:13 -0700, Joe Perches wrote:
> Sorry, not a git developer, so the paths are wrong.
> This seems to work:
Sorry. Patch reversed too.
--- /usr/local/bin/git-send-email 2007-05-01 11:59:14.0 -0700
+++ /home/joe/bin/git-send-email.pl 2007-08-16 19:25:53.000
On Tue, 2007-08-14 at 18:31 -0700, Junio C Hamano wrote:
>On the other hand, git-send-email _is_ all about sending it
>out, and it needs to know who your patch should reach. I
>think it makes sense to have one script that, given a set of
>paths that are affected, gives a list of po
On Tue, 2007-08-14 at 11:40 -0700, Linus Torvalds wrote:
> Do a script like this:
>
> #!/bin/sh
> git log --since=6.months.ago -- "$@" |
> grep -i '^[-a-z]*by:.*@' |
> sort | uniq -c |
> sort -r -n | head
> (Maybe you want to add a
>
Rene Herman <[EMAIL PROTECTED]> writes:
> Am looking at it but am not so sure that's a very good idea. I guess
> it'd be largely okay-ish to require the repo to be on a filesystem
> that supports EAs for this feature to work, but keeping the attributes
> intact over file system operations seems no
On 08/16/2007 05:40 PM, Al Viro wrote:
On Thu, Aug 16, 2007 at 12:58:19PM +0200, Rene Herman wrote:
The git-blame thing as sketched before by Linus would never be able to
point out mailing lists, or general lists of "interested parties" for
example, but these properties can do anything...
On Thu, Aug 16, 2007 at 12:58:19PM +0200, Rene Herman wrote:
> Googling around, I see subversion already has this and calls the meta-data
> "properties" (svn propset/get and friends). It uses a few properties
> itself, such as the svn:executable property (which I saw is also the only
> permiss
On 08/16/2007 01:26 PM, Salikh Zakirov wrote:
Please don't drop CCs.
Rene Herman wrote:
Perhaps that immediately suggests an implementation to someone already
familiar with git internals?
perhaps http://www.kernel.org/pub/software/scm/git/docs/gitattributes.html
and http://www.kernel.org/pub
Rene Herman wrote:
> Perhaps that immediately suggests an implementation to someone already
> familiar with git internals?
perhaps http://www.kernel.org/pub/software/scm/git/docs/gitattributes.html
and http://www.kernel.org/pub/software/scm/git/docs/git-check-attr.html
can help you?
-
To unsubscr
On 08/16/2007 12:58 PM, Rene Herman wrote:
On 08/15/2007 03:52 PM, Kyle Moffett wrote:
If you were going to do that I'd just suggest making git aware of the
"user.*" extended attributes and having it save those into the git
repo along with the permission data.
Am looking at it but am not s
On 08/15/2007 03:52 PM, Kyle Moffett wrote:
On Aug 15, 2007, at 09:39:44, Rene Herman wrote:
On 08/15/2007 03:33 PM, Satyam Sharma wrote:
[ git info --maintainer ]
I'd really _love_ a tool that does all that what you've proposed
above! But why does it have to be "git-info" or anything in th
On Wed, Aug 15, 2007 at 09:37:45PM +0200, Krzysztof Halasa wrote:
> > I'm not suggesting something like [EMAIL PROTECTED] with something
> > like majordomo allowing to add yourself to those,
>
> Why not
You'd need to implement serious anti-spam measures for that. Besides,
cross-postings between
Al Viro <[EMAIL PROTECTED]> writes:
> I'm not suggesting something like [EMAIL PROTECTED] with something
> like majordomo allowing to add yourself to those,
Why not
> but something less
> extreme in that direction might be worth thinking about... Hell,
> even simple
> $ finger fs/minix/[EMAIL P
On Wed, 2007-08-15 at 13:44 +0200, Rene Herman wrote:
> On 08/15/2007 11:39 AM, Stefan Richter wrote:
> > Note, maintainer contacts
> > - should be available to patch submitters and
> > - must be available to *problem reporters*
> > without having to have git and a .git repo.
> That "must" seem
On 8/15/07, Stefan Richter <[EMAIL PROTECTED]> wrote:
> Linus Torvalds wrote:
> > #!/bin/sh
> > git log --since=6.months.ago -- "$@" |
> > grep -i '^[-a-z]*by:.*@' |
> > sort | uniq -c |
> > sort -r -n | head
> >
> > and it gives you a rathe
On Aug 15, 2007, at 09:39:44, Rene Herman wrote:
On 08/15/2007 03:33 PM, Satyam Sharma wrote:
[ git info --maintainer ]
I'd really _love_ a tool that does all that what you've proposed
above! But why does it have to be "git-info" or anything in the
git(7) suite for that matter? This sounds
On 08/15/2007 03:33 PM, Satyam Sharma wrote:
[ git info --maintainer ]
I'd really _love_ a tool that does all that what you've proposed above!
But why does it have to be "git-info" or anything in the git(7) suite for
that matter? This sounds like a job for a different specialised tool,
along
Hi Rene,
On Wed, 15 Aug 2007, Rene Herman wrote:
> It mostly is just about that it seems. However, this would not also allow the
> other information currently in the MAINTAINERS file to be queried in similar
> ways.
>
> Git could grow a generic file meta data implementation through the use of
>
On 08/15/2007 11:39 AM, Stefan Richter wrote:
Note, maintainer contacts
- should be available to patch submitters and
- must be available to *problem reporters*
without having to have git and a .git repo.
That "must" seems rather strong. But those few non-developer users that
could care a
Joe Perches wrote:
> On Tue, 2007-08-14 at 18:31 -0700, Junio C Hamano wrote:
>>On the other hand, git-send-email _is_ all about sending it
>>out, and it needs to know who your patch should reach. I
>>think it makes sense to have one script that,
[...]
> Yes please.
>
> The LK MAINTA
Linus Torvalds wrote:
> #!/bin/sh
> git log --since=6.months.ago -- "$@" |
> grep -i '^[-a-z]*by:.*@' |
> sort | uniq -c |
> sort -r -n | head
>
> and it gives you a rather good picture of who is involved with a
> particular subdirectory o
On 08/15/2007 07:25 AM, Junio C Hamano wrote:
Joe Perches <[EMAIL PROTECTED]> writes:
Rene Herman had an idea about using some git
metadata that might be useful. The completely
external data approach suggested by Al Viro
might be OK too in that it wouldn't tie listeners
to git requiring mo
Joe Perches <[EMAIL PROTECTED]> writes:
> Yes please.
Huh?
> Rene Herman had an idea about using some git
> metadata that might be useful. The completely
> external data approach suggested by Al Viro
> might be OK too in that it wouldn't tie listeners
> to git requiring more content in git met
On Tue, 2007-08-14 at 18:31 -0700, Junio C Hamano wrote:
>On the other hand, git-send-email _is_ all about sending it
>out, and it needs to know who your patch should reach. I
>think it makes sense to have one script that, given a set of
>paths that are affected, gives a list of po
On 08/14/2007 09:33 PM, Al Viro wrote:
FWIW, I suspect that we are looking at that from the wrong POV. If
that's about "who ought to be Cc'd on the issues dealing with ", why does it have to be tied to "who is maintainer for
"?
I'm not suggesting something like [EMAIL PROTECTED] with something
Linus Torvalds wrote:
On Tue, 14 Aug 2007, Joe Perches wrote:
On Tue, 2007-08-14 at 20:03 +0200, Rene Herman wrote:
"git info --maintainer drivers/ide/ide-cd.c" or some such would say "Alan
Cox <[EMAIL PROTECTED]>".
Perhaps maintainer(s), approver(s), listener(s)?
I think some
Joe Perches <[EMAIL PROTECTED]> writes:
> On Tue, 2007-08-14 at 17:53 +0200, Rene Herman wrote:
>> It isn't about MODULE_FOO() tags, it is about tagging /source/ files
>> to help with putting CCs on patch submissals.
>> If we want to link source file foo.c and the
>> MAINTAINERS information, we
On Tue, 2007-08-14 at 20:33 +0100, Al Viro wrote:
> FWIW, I suspect that we are looking at that from the wrong POV. If
> that's about "who ought to be Cc'd on the issues dealing with of pathnames>", why does it have to be tied to "who is maintainer for
> "?
Right, it doesn't have to.
I think a n
On Tue, Aug 14, 2007 at 11:40:09AM -0700, Linus Torvalds wrote:
> A much *better* picture than some manually maintained thing, in fact,
> because it tells you who really does the work, and which way patches go...
>
> (Maybe you want to add a
>
> grep -v '\(Linus Torvalds\)\|\(Andrew Morto
On Tue, 2007-08-14 at 11:40 -0700, Linus Torvalds wrote:
> Anyway - the script can certainly be tweaked, the point is
> really just that the git tree _already_ contains the relevant
> information).
I believe it's not specific enough.
Things like email lists would never show up.
-
To unsubscribe
On Tue, 14 Aug 2007, Joe Perches wrote:
> On Tue, 2007-08-14 at 20:03 +0200, Rene Herman wrote:
> > "git info --maintainer drivers/ide/ide-cd.c" or some such would say "Alan
> > Cox <[EMAIL PROTECTED]>".
>
> Perhaps maintainer(s), approver(s), listener(s)?
>
> I think something like this shou
On 08/14/2007 08:28 PM, Joe Perches wrote:
On Tue, 2007-08-14 at 20:03 +0200, Rene Herman wrote:
"git info --maintainer drivers/ide/ide-cd.c" or some such would say "Alan
Cox <[EMAIL PROTECTED]>".
Perhaps maintainer(s), approver(s), listener(s)?
I think something like this should be a git-go
On Tue, 2007-08-14 at 20:03 +0200, Rene Herman wrote:
> "git info --maintainer drivers/ide/ide-cd.c" or some such would say "Alan
> Cox <[EMAIL PROTECTED]>".
Perhaps maintainer(s), approver(s), listener(s)?
I think something like this should be a git-goal.
What do the git-wranglers think?
Until
On 08/14/2007 07:00 PM, Joe Perches wrote:
On Tue, 2007-08-14 at 17:53 +0200, Rene Herman wrote:
It isn't about MODULE_FOO() tags, it is about tagging /source/ files
to help with putting CCs on patch submissals.
If we want to link source file foo.c and the
MAINTAINERS information, we have 3
On Tue, 2007-08-14 at 17:53 +0200, Rene Herman wrote:
> It isn't about MODULE_FOO() tags, it is about tagging /source/ files
> to help with putting CCs on patch submissals.
> If we want to link source file foo.c and the
> MAINTAINERS information, we have 3 options:
> 1. MAINTAINERS --> foo.c
> 2.
On 08/14/2007 11:20 AM, Alan Cox wrote:
MODULE_MAINTAINER() was discussed a while ago but embedding information into
the binary has the problem you can't ever change deployed systems, meaning
it lags by design. If a maintainer changes, people would still be using the
information from their old
On Tue, Aug 14, 2007 at 04:22:05PM +0200, Adrian Bunk wrote:
> On Mon, Aug 13, 2007 at 06:19:26PM -0700, Arjan van de Ven wrote:
> >
> > On Mon, 2007-08-13 at 16:37 -0400, Trond Myklebust wrote:
> > > On Mon, 2007-08-13 at 10:42 -0700, Arjan van de Ven wrote:
> > > > The maintainer info should be
On Tue, 2007-08-14 at 16:22 +0200, Adrian Bunk wrote:
> > people tend to update .c files a lot better than way off-the-side other
> > files.
>
> The move of netdev to vger would have required updating
> approx. 1300 C files...
and your point is?
This is an easily sed-able operation with a singl
> > the other angle is this: if someone becomes the new maintainer, does he
> > really want to "maintain" all the really old versions of the code out
> > there that predate him, or does he only want to go forward?
> >...
>
> What about cases like maintainers using company email addresses and
>
On Tue, Aug 14, 2007 at 06:47:20AM -0700, Arjan van de Ven wrote:
>
> On Tue, 2007-08-14 at 10:20 +0100, Alan Cox wrote:
> > > MODULE_MAINTAINER() was discussed a while ago but embedding information
> > > into
> > > the binary has the problem you can't ever change deployed systems,
> > > meanin
On Mon, Aug 13, 2007 at 06:19:26PM -0700, Arjan van de Ven wrote:
>
> On Mon, 2007-08-13 at 16:37 -0400, Trond Myklebust wrote:
> > On Mon, 2007-08-13 at 10:42 -0700, Arjan van de Ven wrote:
> > > The maintainer info should be in the source file itself! That's the only
> > > reasonable way to keep
On Tue, 2007-08-14 at 10:20 +0100, Alan Cox wrote:
> > MODULE_MAINTAINER() was discussed a while ago but embedding information
> > into
> > the binary has the problem you can't ever change deployed systems, meaning
> > it lags by design. If a maintainer changes, people would still be using the
> MODULE_MAINTAINER() was discussed a while ago but embedding information into
> the binary has the problem you can't ever change deployed systems, meaning
> it lags by design. If a maintainer changes, people would still be using the
> information from their old binaries, meaning a replaced main
On 8/13/07, Arjan van de Ven <[EMAIL PROTECTED]> wrote:
>
> On Mon, 2007-08-13 at 19:33 +0200, Mariusz Kozlowski wrote:
> > Hello,
> >
> > I don't recall discusion about this so here are my 3 cents:
> >
> > I like the idea.
>
> I don't actually. It shows a central MAINTAINERS file is th
On 08/14/2007 03:51 AM, Rene Herman wrote:
MODULE_MAINTAINER() was discussed a while ago but embedding information
into the binary has the problem you can't ever change deployed systems,
meaning it lags by design. If a maintainer changes, people would still
be using the information from their
On Mon, Aug 13, 2007 at 06:19:26PM -0700, Arjan van de Ven wrote:
>
> On Mon, 2007-08-13 at 16:37 -0400, Trond Myklebust wrote:
> > If the problem is to do with people failing to update the MAINTAINERS
> > file, why would moving the same data into 20 or 30 source files motivate
> > them to keep i
On 08/14/2007 03:19 AM, Arjan van de Ven wrote:
On Mon, 2007-08-13 at 16:37 -0400, Trond Myklebust wrote:
On Mon, 2007-08-13 at 10:42 -0700, Arjan van de Ven wrote:
The maintainer info should be in the source file itself! That's the only
reasonable way to keep it updated; now I'm all for hav
On Mon, 2007-08-13 at 16:37 -0400, Trond Myklebust wrote:
> On Mon, 2007-08-13 at 10:42 -0700, Arjan van de Ven wrote:
> > The maintainer info should be in the source file itself! That's the only
> > reasonable way to keep it updated; now I'm all for having it machine
> > parsable so that tools ca
On Mon, Aug 13, 2007 at 10:09:08AM -0700, Ray Lee wrote:
> On 8/12/07, Joe Perches <[EMAIL PROTECTED]> wrote:
> > I grew weary of looking up the appropriate
> > maintainer email address(es) to CC: for a patch.
> >
> > I added flags to the MAINTAINERS file
> >
> > F: file pattern
> >
> > for ea
Kok, Auke wrote:
Richard Knutsson wrote:
Kok, Auke wrote:
Joe Perches wrote:
I grew weary of looking up the appropriate
maintainer email address(es) to CC: for a patch.
I added flags to the MAINTAINERS file
F:file pattern
for each maintained block and a script to parse
the modified bloc
On Mon, 2007-08-13 at 10:42 -0700, Arjan van de Ven wrote:
> The maintainer info should be in the source file itself! That's the only
> reasonable way to keep it updated; now I'm all for having it machine
> parsable so that tools can use it, but it still really should be in the
> code itself, not i
Richard Knutsson wrote:
Kok, Auke wrote:
Joe Perches wrote:
I grew weary of looking up the appropriate
maintainer email address(es) to CC: for a patch.
I added flags to the MAINTAINERS file
F:file pattern
for each maintained block and a script to parse
the modified blocks for maintainer
On Mon, Aug 13, 2007 at 08:41:03PM +0200, Krzysztof Halasa wrote:
> Arjan van de Ven <[EMAIL PROTECTED]> writes:
>
> > The maintainer info should be in the source file itself!
>
> Nope, it should be outside of the (downloadable) tarball, because
> once someone get a tarball you can't update the d
On Mon, 13 Aug 2007 21:21:10 +0200, Jan Engelhardt said:
>
> On Aug 14 2007 00:02, Satyam Sharma wrote:
> >
> >Better solution is to have multiple MAINTAINERS files distributed in the
> >kernel tree, IMHO -- say a drivers/net/MAINTAINERS for maintainer info on
> >all various net drivers, drivers/k
Jan Engelhardt wrote:
On Aug 14 2007 00:02, Satyam Sharma wrote:
Better solution is to have multiple MAINTAINERS files distributed in the
kernel tree, IMHO -- say a drivers/net/MAINTAINERS for maintainer info on
all various net drivers, drivers/kvm/MAINTAINERS for KVM maintainer info,
fs/ext3
Kok, Auke wrote:
Joe Perches wrote:
I grew weary of looking up the appropriate
maintainer email address(es) to CC: for a patch.
I added flags to the MAINTAINERS file
F:file pattern
for each maintained block and a script to parse
the modified blocks for maintainer and list
email addresses.
On Aug 14 2007 00:02, Satyam Sharma wrote:
>
>Better solution is to have multiple MAINTAINERS files distributed in the
>kernel tree, IMHO -- say a drivers/net/MAINTAINERS for maintainer info on
>all various net drivers, drivers/kvm/MAINTAINERS for KVM maintainer info,
>fs/ext3/MAINTAINERS for ext3
Krzysztof Halasa <[EMAIL PROTECTED]> writes:
> Nope, it should be outside of the (downloadable) tarball, because
> once someone get a tarball you can't update the data in it.
> This is fine WRT source (which is static given a version) but
> doesn't work for fast-changing data.
... OTOH I think th
Arjan van de Ven <[EMAIL PROTECTED]> writes:
> The maintainer info should be in the source file itself!
Nope, it should be outside of the (downloadable) tarball, because
once someone get a tarball you can't update the data in it.
This is fine WRT source (which is static given a version) but
doesn
On Mon, 13 Aug 2007, Arjan van de Ven wrote:
>
> On Mon, 2007-08-13 at 19:33 +0200, Mariusz Kozlowski wrote:
> > Hello,
> >
> > I don't recall discusion about this so here are my 3 cents:
> >
> > I like the idea.
>
> I don't actually. It shows a central MAINTAINERS file is the wrong
On 08/13/2007 07:42 PM, Arjan van de Ven wrote:
On Mon, 2007-08-13 at 19:33 +0200, Mariusz Kozlowski wrote:
Hello,
I don't recall discusion about this so here are my 3 cents:
I like the idea.
I don't actually. It shows a central MAINTAINERS file is the wrong
approach; just that 50
On Mon, 13 Aug 2007 10:09:08 PDT, Ray Lee said:
> On 8/12/07, Joe Perches <[EMAIL PROTECTED]> wrote:
> > I grew weary of looking up the appropriate
> > maintainer email address(es) to CC: for a patch.
> >
> > I added flags to the MAINTAINERS file
> >
> > F: file pattern
> >
> > for each mainta
> > I don't recall discusion about this so here are my 3 cents:
> >
> > I like the idea.
>
> I don't actually. It shows a central MAINTAINERS file is the wrong
> approach; just that 500+ patches to the same file were needed shows
> that.
>
> The maintainer info should be in the source
On Mon, 2007-08-13 at 19:33 +0200, Mariusz Kozlowski wrote:
> Hello,
>
> I don't recall discusion about this so here are my 3 cents:
>
> I like the idea.
I don't actually. It shows a central MAINTAINERS file is the wrong
approach; just that 500+ patches to the same file were needed
On 08/13/2007 09:16 AM, Al Viro wrote:
On Sun, Aug 12, 2007 at 10:49:34PM -0700, Joe Perches wrote:
I grew weary of looking up the appropriate
maintainer email address(es) to CC: for a patch.
Does the acronym GAFL ring any bells? It's not that idea is worthless -
it sure as hell is a useful
Hello,
I don't recall discusion about this so here are my 3 cents:
I like the idea. The numerous responses you got that you made a mistake
and someone else is the maintainer just prove that this kind of information
would
be nice to have. Even if it is not going to be included in
On 8/12/07, Joe Perches <[EMAIL PROTECTED]> wrote:
> I grew weary of looking up the appropriate
> maintainer email address(es) to CC: for a patch.
>
> I added flags to the MAINTAINERS file
>
> F: file pattern
>
> for each maintained block and a script to parse
> the modified blocks for maintai
>
> Please, people, try to think for a minute. Patch series are good not
> just because; there are rational reasons for that. None of those
> applies here; if anything, you've made sure that this patchbomb will
> be less reviewed.
This huge serie had one nice property.
Relavent people got only
On Sun, Aug 12, 2007 at 11:09:01PM -0700, Joe Perches wrote:
> Forgot
Could you please in the usage give a short intro to
what is the actual purpose of this script.
And no - I do not like the unix style where programs
says nada what they are supposed to do.
Sam
-
To unsubscribe from this
Joe Perches wrote:
I grew weary of looking up the appropriate
maintainer email address(es) to CC: for a patch.
I added flags to the MAINTAINERS file
F: file pattern
for each maintained block and a script to parse
the modified blocks for maintainer and list
email addresses.
perl scripts/g
On Sun, Aug 12, 2007 at 10:49:34PM -0700, Joe Perches wrote:
> I grew weary of looking up the appropriate
> maintainer email address(es) to CC: for a patch.
Does the acronym GAFL ring any bells? It's not that idea is worthless -
it sure as hell is a useful thing, but what the bleeding hell is tha
Hey Joe,
On 13/08/07, Joe Perches <[EMAIL PROTECTED]> wrote:
> I grew weary of looking up the appropriate
> maintainer email address(es) to CC: for a patch.
>
> I added flags to the MAINTAINERS file
>
> F: file pattern
>
> for each maintained block and a script to parse
> the modified blocks
Forgot
Signed-off-by: Joe Perches <[EMAIL PROTECTED]>
diff --git a/scripts/get_maintainer.pl b/scripts/get_maintainer.pl
new file mode 100755
index 000..3e5cc6c
--- /dev/null
+++ b/scripts/get_maintainer.pl
@@ -0,0 +1,217 @@
+#!/usr/bin/perl -w
+# (c) 2007, Joe Perches <[EMAIL PROTECTED]>
+#
I grew weary of looking up the appropriate
maintainer email address(es) to CC: for a patch.
I added flags to the MAINTAINERS file
F: file pattern
for each maintained block and a script to parse
the modified blocks for maintainer and list
email addresses.
perl scripts/get_maintainer.pl
gi
I grew weary of looking up the appropriate
maintainer email address(es) to CC: for a patch.
I added flags to the MAINTAINERS file
F: file pattern
for each maintained block and a script to parse
the modified blocks for maintainer and list
email addresses.
perl scripts/get_maintainer.pl
gi
86 matches
Mail list logo
