- FInd the maintainer(s) for a patch - scripts/get_maintainer.pl

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 <patch>

gives the appropriate maintainer(s).

I grew weary of looking up the appropriate
maintainer email address(es) to CC: for a patch.

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.

Quoted 2 lines · Joe Perches

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 that splitup supposed to achieve?

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 <patch>

gives the appropriate maintainer(s).

Modifications since last post:

Added options to control email address style and multiple address separator

Please apply.

scripts/get_maintainer.pl new file +217 -1

new file mode 100755
index 0000000..3e5cc6c
@@ -0,0 +1,217 @@
+#!/usr/bin/perl -w
+# (c) 2007, Joe Perches <[email protected]>
+#           created from checkpatch.pl
+# Licensed under the terms of the GNU GPL License version 2
+
+use strict;
+
+my $P = $0;
+$P =~ s@.*/@@g;
+
+my $V = '0.02';
+
+use Getopt::Long qw(:config no_auto_abbrev);
+
+my $tree = "./";
+my $email_maintainer = 1;
+my $email_maintainer_name = 1;
+my $email_list = 1;
+my $email_subscriber_list = 0;
+my $email_separator = ", ";
+my %saw;
+
+GetOptions(
+	   'tree=s' => \$tree,
+	   'm!' => \$email_maintainer,
+	   'n!' => \$email_maintainer_name,
+	   'l!' => \$email_list,
+	   's!' => \$email_subscriber_list,
+	   'separator=s' => \$email_separator,
+	   ) or exit;
+
+my $exit = 0;
+
+if ($#ARGV < 0 ||
+    ($email_maintainer == 0 && $email_list == 0 && $email_subscriber_list == 0)) {
+    print "usage: $P [options] patchfile\n";
+    print "version: $V\n";
+    print "  --tree [path] => linux kernel source path\n";
+    print "  --m => include maintainer(s) if any\n";
+    print "  --n => include maintainer name 'Full Name <addr\@domain.tld>'\n";
+    print "  --l => include list(s) if any\n";
+    print "  --s => include subscriber only list(s) if any\n";
+    print "  --separator [, ] => separator for multiple addresses\n";
+    print "Default: [--m --l --separator \", \"]\n";
+    print "Be sure to select something...\n";
+    exit(1);
+}
+
+if ($tree && !top_of_kernel_tree($tree)) {
+    if (${tree} ne "") {
+	print "'${tree}' ";
+    } else {
+	print "The current directory ";
+    }
+    print "doesn't appear to be a linux kernel source tree\n";
+    exit(2);
+}
+
+## Read MAINTAINERS for type/value pairs
+
+my @typevalue = ();
+open(MAINT, "<${tree}MAINTAINERS") || die "$P: Can't open ${tree}MAINTAINERS\n";
+while (<MAINT>) {
+    if (m/^(\C):\s*(.*)/) {
+	my $type = $1;
+	my $value = $2;
+	if ($type eq "F") {              ##Filename pattern matching
+	    $value =~ s@\.@\\\.@g;       ##Convert . to \.
+	    $value =~ s/\*/\.\*/g;       ##Convert * to .*
+	}
+	push(@typevalue, "$type:$value");
+    } elsif (!/^(\s)*$/) {
+	push(@typevalue, $_);
+    }
+}
+close(MAINT);
+
+## Find the patched filenames
+
+my @patchedfiles = ();
+open(PATCH, "<$ARGV[0]") or die "Can't open $ARGV[0]\n";
+while (<PATCH>) {
+    if (m/^\+\+\+\s+(\S+)/) {
+	my $file = $1;
+	$file =~ s@^[^/]*/@@;
+	$file =~ s@\n@@;
+	push(@patchedfiles, $file);
+    }
+}
+close(PATCH);
+
+# Sort and uniq patchedfiles
+
+undef %saw;
+@patchedfiles = sort @patchedfiles;
+@patchedfiles = grep(!$saw{$_}++, @patchedfiles);
+
+# Find responsible parties
+
+my @email_to = ();
+foreach (@patchedfiles) {
+    my $patchedfile = $_;
+    my $tvi = 0;
+
+    foreach (@typevalue) {
+	if (m/^(\C):(.*)/) {
+	    my $type = $1;
+	    my $value = $2;
+	    if ($type eq 'F') {
+		if (file_match_pattern($patchedfile, $value)) {
+		    my $ptvi = $tvi - 1;
+		    while ($ptvi >= 0) {
+			my $tv = $typevalue[$ptvi];
+			if ($tv =~ m/^(\C):(.*)/) {
+			    my $ptype = $1;
+			    my $pvalue = $2;
+			    if ($ptype eq "L") {
+				my $subscr = $pvalue;
+				if ($subscr =~ m/\s*\(subscribers-only\)/) {
+				    if ($email_subscriber_list > 0) {
+					$subscr =~ s/\s*\(subscribers-only\)//g;
+					push(@email_to, $subscr);
+				    }
+				} else {
+				    if ($email_list > 0) {
+					push(@email_to, $pvalue);
+				    }
+				}
+			    } elsif ($ptype eq "M") {
+				if ($email_maintainer > 0) {
+				    if ($ptvi >= 0) {
+					my $tv = $typevalue[$ptvi - 1];
+					if ($tv =~ m/^(\C):(.*)/) {
+					    if ($1 eq "P" && $email_maintainer_name > 0) {
+						push(@email_to, "$2 <$pvalue>");
+					    } else {
+						push(@email_to, $pvalue);
+					    }
+					}
+				    } else {
+					push(@email_to, $pvalue);
+				    }
+				}
+			    }
+			    $ptvi--;
+			} else {
+			    $ptvi = -1;
+			}
+		    }
+		}
+	    }
+	}
+	$tvi++;
+    }
+}
+
+## sort and uniq email_to
+
+@email_to = sort @email_to;
+undef %saw;
+@email_to = grep(!$saw{$_}++, @email_to);
+
+## add lk if noone else...
+
+my $address_cnt = @email_to;
+if ($address_cnt == 0 && $email_list > 0) {
+    push(@email_to, "linux-kernel\@vger.kernel.org");
+}
+print(join($email_separator, @email_to));
+print("\n");
+
+exit($exit);
+
+sub file_match_pattern {
+    my ($file, $pattern) = @_;
+    if (substr($pattern, -1) eq "/") {
+	if ($file =~ m@^$pattern@) {
+	    return 1;
+	}
+    } else {
+	if ($file =~ m@^$pattern@) {
+	    my $s1 = ($file =~ tr@/@@);
+	    my $s2 = ($pattern =~ tr@/@@);
+	    if ($s1 == $s2) {
+		return 1;
+	    }
+	}
+    }
+    return 0;
+}
+
+sub top_of_kernel_tree {
+	my ($tree) = @_;
+
+	if ($tree ne "" && substr($tree,length($tree)-1,1) ne "/") {
+	    $tree = $tree . "/";
+	}
+	if (   (-f "${tree}COPYING")
+	    && (-f "${tree}CREDITS")
+	    && (-f "${tree}Kbuild")
+	    && (-f "${tree}MAINTAINERS")
+	    && (-f "${tree}Makefile")
+	    && (-f "${tree}README")
+	    && (-d "${tree}Documentation")
+	    && (-d "${tree}arch")
+	    && (-d "${tree}include")
+	    && (-d "${tree}drivers")
+	    && (-d "${tree}fs")
+	    && (-d "${tree}init")
+	    && (-d "${tree}ipc")
+	    && (-d "${tree}kernel")
+	    && (-d "${tree}lib")
+	    && (-d "${tree}scripts")) {
+		return 1;
+	}
+	return 0;
+}
 
 
-

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Quoted 15 lines · Joe Perches

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 <patch>

gives the appropriate maintainer(s).

Quoted 5 lines

Modifications since last post:

Added options to control email address style and multiple address separator

Please apply.

Well, I came up with this implementation, so I definately support it and the way Joe implemented it:

Quoted 21 lines · Auke

Quoted 20 lines · Joe Perches

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 <patch>

gives the appropriate maintainer(s).

Modifications since last post:

Added options to control email address style and multiple address separator

Please apply.

Quoted 2 lines

Well, I came up with this implementation, so I definately support it and the way Joe implemented it:

Really? Please check out this thread with at least two ideas of possible implementations, with Stefan Richter as the spokesman of the current implementation: http://marc.info/?l=linux-kernel&m=116870578531280&w=3
...and I am not saying there hasn't been someone suggesting it even earlier.

The expression; nothing is new under the sun comes to mind ;)

Anyway, glad to see someone actually implementing it. Thanks!

Quoted 24 lines · Richard Knutsson

Quoted 23 lines · Auke

Quoted 13 lines · Joe Perches

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 <patch>

Quoted 7 lines

gives the appropriate maintainer(s).

Modifications since last post:

Added options to control email address style and multiple address separator

Please apply.

Well, I came up with this implementation, so I definately support it and the way Joe implemented it:

Quoted 6 lines

Really? Please check out this thread with at least two ideas of possible implementations, with Stefan Richter as the spokesman of the current implementation: http://marc.info/?l=linux-kernel&m=116870578531280&w=3
...and I am not saying there hasn't been someone suggesting it even earlier.

The expression; nothing is new under the sun comes to mind ;)

Anyway, glad to see someone actually implementing it. Thanks!

bad wording my side, I never implemented anything, but I did post the "F:" flag idea specific to allocating files to developers on lkml: http://lkml.org/lkml/2007/6/29/300

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.

Quoted 7 lines · Joe Perches

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

Quoted 3 lines

for each maintained block and a script to parse
the modified blocks for maintainer and list
email addresses.

Why not parse git annotate or blame instead (other than it's freakin' slow)? Using the repository history has the added benefit of telling you a lot more fine-grained detail about who may want to know about your patch.

Quoted 7 lines · Joe Perches

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

Quoted 3 lines

for each maintained block and a script to parse
the modified blocks for maintainer and list
email addresses.

Why not parse git annotate or blame instead (other than it's freakin' slow)? Using the repository history has the added benefit of telling you a lot more fine-grained detail about who may want to know about your patch.

Hello,

I don't recall discusion about this so here are my 3 cents:

I like the idea.

Quoted 3 lines

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 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 in some central file that will always just go out of data, and will be a huge source of needless patch conflicts.

Quoted 5 lines · Mariusz Kozlowski

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 shows that.

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 in some central file that will always just go out of data, and will be a huge source of needless patch conflicts.

Quoted 5 lines · Mariusz Kozlowski

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 shows that.

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 in some central file that will always just go out of data, and will be a huge source of needless patch conflicts.

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 maintainers, fs/MAINTAINERS for generic VFS maintainers info, so on and so forth. Of course, these individual MAINTAINERS files could still have the newly-introduced "F:" fields as well (drivers/net/MAINTAINERS would clearly require it, f.e.) ...

Quoted 8 lines · Satyam Sharma

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 maintainers, fs/MAINTAINERS for generic VFS maintainers info, so on and so forth. Of course, these individual MAINTAINERS files could still have the newly-introduced "F:" fields as well (drivers/net/MAINTAINERS would clearly require it, f.e.) ...

Yes please.

Or perhaps even putting the maintainer into the Kconfig files?

Quoted 8 lines · Satyam Sharma

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 maintainers, fs/MAINTAINERS for generic VFS maintainers info, so on and so forth. Of course, these individual MAINTAINERS files could still have the newly-introduced "F:" fields as well (drivers/net/MAINTAINERS would clearly require it, f.e.) ...

Yes please.

Or perhaps even putting the maintainer into the Kconfig files?

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't work for fast-changing data.

Quoted 1 line · Arjan van de Ven

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't work for fast-changing data.

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 in some central file that will always just go out of data, and will be a huge source of needless patch conflicts.

Quoted 5 lines · Arjan van de Ven

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 in some central file that will always just go out of data, and will be a huge source of needless patch conflicts.

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 it up to date? As far as I can see, that would just serve to multiply the amount of stale data...

Quoted 8 lines · Trond Myklebust

Quoted 5 lines · Arjan van de Ven

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 in some central file that will always just go out of data, and will be a huge source of needless patch conflicts.

Quoted 3 lines

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 it up to date? As far as I can see, that would
just serve to multiply the amount of stale data...

if each .c file has a MODULE_MAINTAINER() tag...

people tend to update .c files a lot better than way off-the-side other files.

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 maintainer might get contacted for potentially years still (and the new one not).

(you could avoid that by placing not a name/address in the maintainer tag but a pointer to somewhere else but at that point this gets to be about solving something else).

Keeping it in the source alone is fine. C files could just embed their MAINTAINERS entry as a header:

/*
* P: Maintainer
* M: Mail patches to
* L: Mailing list that is relevant to this area
* W: Web-page with status/info
* T: SCM tree type and location. Type is one of: git, hg, quilt.
* S: Status, one of the following:
*/

And probably adding fields:

* I: Info/Summary (for index files and the like)
* A: Author
* G: License

and such. Yes, while we're at it, we can pick better letters or full word tags ;-)

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 maintainer might get contacted for potentially years still (and the new one not).

Quoted 5 lines

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 maintainer might get contacted for potentially years still (and the new one not).

And as was pointed out at the time, the people whining about that were talking out of the wrong equipment. The supplier of the code can no more or less easily change the binary as the matching source tree once its been shipped. In fact its probably easier to change the binaries as the sources will be left on CD.

The only non-stale source is git-blame.

Quoted 12 lines · Alan Cox

Quoted 5 lines

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 maintainer might get contacted for potentially years still (and the new one not).

And as was pointed out at the time, the people whining about that were talking out of the wrong equipment. The supplier of the code can no more or less easily change the binary as the matching source tree once its been shipped. In fact its probably easier to change the binaries as the sources will be left on CD.

Quoted 1 line

The only non-stale source is git-blame.

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?
...

Quoted 5 lines

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 changing company?

E.g. Jens is still block layer maintainer but the @suse address he used for years suddenly no longer existed after he left Suse.

Quoted 1 line

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 maintainer might get contacted for potentially years still (and the new one not).

And as was pointed out at the time, the people whining about that were talking out of the wrong equipment. The supplier of the code can no more or less easily change the binary as the matching source tree once its been shipped. In fact its probably easier to change the binaries as the sources will be left on CD.

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. foo.c --> MAINTAINERS
3. foo.c <--> some 3rd file <--> MAINTAINERS

Quoted 5 lines · Rene Herman

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. foo.c --> MAINTAINERS
3. foo.c <--> some 3rd file <--> MAINTAINERS

I added [email protected] and Junio Hamano

"git info --maintainer drivers/ide/ide-cd.c" or some such would say "Alan Cox <alan@...>".

sticking headers on every source file isn't nice anyway -- it's meta-information and the SCM can maintain it.

Quoted 1 line · Rene Herman

"git info --maintainer drivers/ide/ide-cd.c" or some such would say "Alan Cox <alan@...>".

Perhaps maintainer(s), approver(s), listener(s)?

I think something like this should be a git-goal.
What do the git-wranglers think?

Until a time in the future when a system like that exists, I suggest keeping MAINTAINERS up-to-date with

F: pattern

It'll be useful as git-set-maintainer seeds at least.

Quoted 2 lines

sticking headers on every source file isn't nice anyway -- it's meta-information and the SCM can maintain it.

It's like looking at $CVS$ keywords. Unsightly.

Quoted 2 lines · Rene Herman

"git info --maintainer drivers/ide/ide-cd.c" or some such would say "Alan Cox <alan@...>".

Perhaps maintainer(s), approver(s), listener(s)?

I think something like this should be a git-goal.
What do the git-wranglers think?

Anyway - the script can certainly be tweaked, the point is really just that the git tree _already_ contains the relevant information).

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 Morton\)'

to avoid seeing the normal chain too much, but hey, we probably want to know too. Anyway - the script can certainly be tweaked, the point is really just that the git tree _already_ contains the relevant information).

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 <list of pathnames>", why does it have to be tied to "who is maintainer for <pathname>"?

I'm not suggesting something like [email protected] with something like majordomo allowing to add yourself to those, but something less extreme in that direction might be worth thinking about... Hell, even simple

$ finger fs/minix/[email protected]
with majordomo-like interface for adding yourself to such lists
might solve most of those problems...

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 <list of pathnames>", why does it have to be tied to "who is maintainer for <pathname>"?

I'm not suggesting something like [email protected] with something like majordomo allowing to add yourself to those, but something less extreme in that direction might be worth thinking about... Hell, even simple

$ finger fs/minix/[email protected]
with majordomo-like interface for adding yourself to such lists
might solve most of those problems...

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 tags, sort of like tags on multimedia files although while with multimedia files the tags are in fact stored as a file header, here you'd keep them just in git. Any project using git would be free to define its own set of info tags and you'd supply them to git simply as a list of

<tag>=<value>

pairs:

$ git info --add drivers/ide/ide-cd.c <<EOF
CC="Alan Cox <[email protected]>", [email protected]
EOF

Or as a more expansive example, with the tags set on a directory (and the output shown this time):

$ git info drivers/infiniband/
CC="Roland Dreier <[email protected]>"
CC="Sean Hefty <[email protected]>"
CC="Hal Rosenstock <[email protected]>"
[email protected]

W=http://www.openib.org/
T=git kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git

$ git info --type="W" drivers/infiniband/
http://www.openib.org/

The project can link the actual tags such as CC, W and T to --options for the "info" command in the git configuration file for the tree (and/or just define a few upfront I guess) making it look nicer:

$ git info --cc drivers/infiniband/
"Roland Dreier <[email protected]>"
"Sean Hefty <[email protected]>"
"Hal Rosenstock <[email protected]>"
[email protected]

$ git info --website drivers/infiniband/
http://www.openib.org/

$ git info --tree drivers/infiniband/
git kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git

Extra: when you have such an implementation, you can use it for other purposes as well such as the summary Documentation/ files want for the 00-INDEX files:

$ git info --summary Documentation/BUG-HUNTING
brute force method of doing binary search of patches to find bug.

And importantly -- when queuried for a file that itself doesn't have the requested info tag:

$ git info --cc drivers/infiniband/core/addr.c

git looks for the tag on the drivers/infiniband/core/ directory next, and then on drivers/infiniband/, where it finds it. [email protected] would be the final fallback, being set on the project root.

I'd really like something like this. As long as projects are both free to use and not use them and free to define their own set of tags I believe this would work very nicely.

Once you have these tags, you can basically use them for anything.

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 with ".metatags" kind of files dispersed in the source tree.

On 08/15/2007 03:33 PM, Satyam Sharma wrote:

[ git info --maintainer ]

Quoted 1 line

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, long with ".metatags" kind of files dispersed in the source tree.

To automatically move (and delete) the meta-data alongside the files themselves is a reason.

More generally -- shouldn't it? This is about source management (well, maybe more about project management, but...) and the source code management tool looks to be the right place for that. The different parts of git are somewhat/fairly stand-alone as is, no?

Quoted 4 lines · Rene Herman

On 08/15/2007 03:33 PM, Satyam Sharma wrote:

[ git info --maintainer ]

Quoted 5 lines

Quoted 1 line

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, long with ".metatags" kind of files dispersed in the source tree.

To automatically move (and delete) the meta-data alongside the files themselves is a reason.

More generally -- shouldn't it? This is about source management (well, maybe more about project management, but...) and the source code management tool looks to be the right place for that. The different parts of git are somewhat/fairly stand-alone as is, no?

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.

Quoted 1 line · Kyle Moffett

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 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 not all that easy (yet). Having not used EAs before I may be missing something but my version of "cp" for example (GNU coreutils 6.9) appears to not copy them. Nor do they seem to survive a trip through GNU tar 1.16.1. EAs appear to not be very useful unless every single tool supports them -- a repo should be resistant against simple operations like that.

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 permission bit git keeps) and svn:ignore, which serves the same role as the .gitignore files for git. Both those would fit into this scheme nicely for git as well, if git were to do something similar and reserve for example the "git.*" namespace for internal use.

Junio (and others), do you have an opinion on this? If these properties are versioned themselves such as in svn I believe it's a decidedly non-trivial addition (and I'm a complete git newbie) but to me, they look incredibly useful, both for the original "maintainers" properties (and anyone else one would want to come up with such as summary properties and author/license stuff) and even for git internal reasons such as sketched above.

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...

Perhaps that immediately suggests an implementation to someone already familiar with git internals?

Quoted 2 lines · Rene Herman

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?

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 permission bit git keeps) and svn:ignore, which serves the same role as the .gitignore files for git. Both those would fit into this scheme nicely for git as well, if git were to do something similar and reserve for example the "git.*" namespace for internal use.

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...

Quoted 1 line · Rene Herman

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...

No, they can not. "I'm interested in drivers/foo/bar.c fixes" is not an earth-shattering event and it sure as hell does not create a new revision of the tree.

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 not all that easy (yet). Having not used EAs before I may be missing something but my version of "cp" for example (GNU coreutils 6.9) appears to not copy them. Nor do they seem to survive a trip through GNU tar 1.16.1. EAs appear to not be very useful unless every single tool supports them -- a repo should be resistant against simple operations like that.

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 permission bit git keeps) and svn:ignore, which serves the same role as the .gitignore files for git. Both those would fit into this scheme nicely for git as well, if git were to do something similar and reserve for example the "git.*" namespace for internal use.

Junio (and others), do you have an opinion on this?

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 would become the single file many subsystem people need to update and is asking for merge conflicts, but I think a file with known name (say, "CcMe.txt") sprinkled in relevant subdirectories, perhaps with the same format originally suggested for MAINTAINERS, would make a lot more sense.

That would give people who work with tarballs and patches, or a subsystem managed with something other than git (one of the most important one is quilt), the equal access to the necessary data.

Even with git, it is my understanding that kernel community works largely on patches exchanged over e-mails, between people who do use git and people who do not. You would want to have something you can easily transfer over e-mail in the patch form.

We _could_ invent a new "patches to properties" git diff output format that "git apply" can understand to propagate that information

but that approach is making it less interoperable with others, and you need to demonstrate the benefit far outweighs that. I do not see it for this particular application.

There may be places for "properties" that would be useful to git, but I do not think the "find whom to send patches to" is one of them.

I'm not suggesting something like [email protected] with something like majordomo allowing to add yourself to those,

but something less
extreme in that direction might be worth thinking about... Hell, even simple

$ finger fs/minix/[email protected]
with majordomo-like interface for adding yourself to such lists
might solve most of those problems...

Quoted 2 lines

I'm not suggesting something like [email protected] with something like majordomo allowing to add yourself to those,

Why not

Quoted 9 lines · Joe Perches

Quoted 2 lines · Rene Herman

"git info --maintainer drivers/ide/ide-cd.c" or some such would say "Alan Cox <alan@...>".

Perhaps maintainer(s), approver(s), listener(s)?

I think something like this should be a git-goal.
What do the git-wranglers think?

The thing is, if you have git, you can basically already do this.

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

and it gives you a rather good picture of who is involved with a particular subdirectory or file.

	#!/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 or file.

Quoted 6 lines · Linus Torvalds

      #!/bin/sh
      git log --since=6.months.ago -- "$@" |
              grep -i '^    [-a-z]*by:.*@' |
              sort | uniq -c |
              sort -r -n | head

Quoted 2 lines

and it gives you a rather good picture of who is involved with a particular subdirectory or file.

No, it doesn't. The subscribers of <[email protected]> are not listed in patch logs.

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
	grep -v '\(Linus Torvalds\)\|\(Andrew Morton\)'

to avoid seeing the normal chain too much, but hey, we probably want to know too. Anyway - the script can certainly be tweaked, the point is really just that the git tree _already_ contains the relevant information).

Quoted 7 lines · Rene Herman

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. foo.c --> MAINTAINERS
3. foo.c <--> some 3rd file <--> MAINTAINERS

I added [email protected] and Junio Hamano

Another possibility is improving git to allow
some sort of "declaration of interest" in bits
of projects.

That would allow options like:

o git-format-patch to include CCs
o git-commit and git-branch to notify or
take some other action

etc...

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 potentially interested people (that is "Finding" part -- and I see there are 600+ patches to implement this on the list), and a new option to git-send-email to (1) inspect the patch to see what paths are affected, and (2) call that "Find" script to figure out whom to send it to, and probably asking for confirmation.

Yes please.

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 metadata.

Quoted 4 lines · Joe Perches

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 metadata.

The reason I found Linus's suggestion desirable is because it fundamentally does not require git to track any metadata. If the commits are in git, then his script would let you gather the data, but otherwise you should be able to do the same by grepping patches. Obviously you would need to filter by paths, looking at the diffstat, but the approach does _not_ tie users to git.

Quoted 3 lines · Junio C Hamano

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 MAINTAINERS file is ugly.

Might there be a git portable way to "find"?

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.

Quoted 4 lines · Stefan Richter

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 are served by a MAINTAINERS file generated into releases.

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 potentially interested people (that is "Finding" part -- and I see there are 600+ patches to implement this on the list), and a new option to git-send-email to (1) inspect the patch to see what paths are affected, and (2) call that "Find" script to figure out whom to send it to, and probably asking for confirmation.

Sorry, not a git developer, so the paths are wrong. This seems to work:

Here's a path to enable a command line option that takes a string argument

cc-cmd

This modifies the @cc array to include whatever output is produced by cc_cmd $patchfile

cccmd can be stored in a config settings file

previous versions of this patch were submitted against an older version of git-send-email.perl

git-send-email.perl +0 -0

index 69559b2..828a77a 100755

git-send-email.perl +1 -0

@@ -652,11 +657,21 @@ foreach my $t (@files) {
 		}
 	}
 	close F;
+

Joe Perches <[email protected]> writes:
... Signed-off-by: ...
I do not see a patch to "Documentation/git-send-email.txt" here... Something like this, with appropriate error checking, perhaps?

	open my $cc, "${cc_cmd} $t |";
        while (my $c = <$cc>) {
        	...
	}
        close $cc;

Quoted 4 lines · Trond Myklebust

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 it up to date? As far as I can see, that would just serve to multiply the amount of stale data...

if each .c file has a MODULE_MAINTAINER() tag...

people tend to update .c files a lot better than way off-the-side other files.

Quoted 11 lines · Trond Myklebust

Quoted 5 lines · Arjan van de Ven

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 in some central file that will always just go out of data, and will be a huge source of needless patch conflicts.

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 it up to date? As far as I can see, that would just serve to multiply the amount of stale data...

if each .c file has a MODULE_MAINTAINER() tag...

people tend to update .c files a lot better than way off-the-side other files.

Quoted 2 lines

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...

Quoted 14 lines · Arjan van de Ven

Quoted 11 lines · Trond Myklebust

Quoted 5 lines · Arjan van de Ven

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 in some central file that will always just go out of data, and will be a huge source of needless patch conflicts.

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 it up to date? As far as I can see, that would just serve to multiply the amount of stale data...

Quoted 4 lines

if each .c file has a MODULE_MAINTAINER() tag...

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...

Quoted 5 lines · Mariusz Kozlowski

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 shows that.

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 in some central file that will always just go out of data, and will be a huge source of needless patch conflicts.