Man, if only we had log message templates... [cmpilato ducks and runs]
kfogel@collab.net writes:
> 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
---------------------------------------------------------------------
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:40:34 2005