Hey committers,
We're getting a lot of new developers, some of whom may in time become
committers. Not just the Summer of Code folks; new people are showing
up with patches completely independently.
I'm no longer able to keep track of it all in my head. When I review
a patch from Contributor Q, I can't remember how many previous patches
have been applied from Q, nor what they were about. I also can't
remember how often Q has contributed analysis or code review. To find
this stuff out, I have to do ad hoc grepping through the commit logs,
and even that's only useful when there's a particular individual on
whom to index the search. But what I'd *really* like is a way to say
"Show me who's been active in the last N months, and how, so I know
who to examine more closely for possible proposal as a partial or full
committer."
Here's a low-overhead proposal for getting us there:
Let's use a parseable format in log messages, for recording code
contributions, analysis, and review. The format would look something
like this:
------------------------------------------------------------------------
r560592 | xqr | 2010-07-09 18:55:02 -0500 (Fri, 09 Jul 2010) | 12 lines
Fix issue #99999: 'svn diff --diff-cmd' failed to blah blah blah.
* subversion/libsvn_client/blah.c
(blah): Blah blah blah.
(blahbittyblah): Blahbitty blah blah blah.
Patch by: Someone's Name <optional@email.address>
Analysis by: So And So <oh.i.should.use@example.com>
Some Other Name <but.i.hate@example.com>
Reviewed by: Another Name <another.optional@email.address>
Still Another Name <etc@etc.etc>
A Third Name <you@get.the.idea>
------------------------------------------------------------------------
A typical log message probably wouldn't have so many fields, I just
wanted this example to show that:
- A field name starts at the beginning of a line.
- Any amount of whitespace after the colon is okay.
- Multiple fields are allowed in a single log message.
- With a field, multiple people can be named, one per line,
with each line after the first starting with whitespace
(so we can tell we're still "in that field").
It doesn't matter where the fields go. Above they're at the end, but
we could put them at the beginning too. Scripts shouldn't enforce it,
we can just settle on a convention, or not, as we please. Merely
*having* the fields is enough to achieve parseability, which is all
that matters.
The fields I'd like to use are:
Patch by:
Analysis by:
Reviewed by:
Approved by: ### We already use this one. ###
One question is how to handle when someone reviews rN, resulting in a
"follow up" commit r(N+M). Putting "Reviewed by: Foo" in r(N+M)'s log
message wouldn't be quite right -- what Foo really reviewed was rN.
We could go back and propedit rN, but that would be cumbersome. Or we
could just overload the Analysis field; that might be easiest.
Another solution is to formalize the followup convention:
Followup to: rN
Suggested by: Foo <rNreviewer@nitpickers.com>
Thoughts welcome on this question, though it's a minor addendum and
not central to the proposal. For now I'll just assume we overload
Analysis.
I can go back and fix up our old log messages (thank you, Emacs), add
the appropriate material to HACKING, and write script(s) for parsing
log messages to use this information.
Any objections to doing this? Would anyone find it burdensome to
follow such conventions? I think we've grown to the point where we
need some kind of automation for monitoring contributors, otherwise
we're liable to let people fall through the cracks.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jul 14 00:34:08 2005