[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Parseable tracking of code contributions.

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: 2005-07-14 00:37:53 CEST

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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.