"C. Michael Pilato" <cmpilato@collab.net> writes:
> Man, if only we had log message templates... [cmpilato ducks and runs]
Heh. Yeah, when we do, we'll put this there. But our committers are
plenty capable of hacking up their own templating systems until then,
anyway, if they want.
When I woke up today, I said to myself: I can work more on the log
message templates situation, and thereby maybe get one feature closer
to existing, or I can work on things that can lead to more committers,
thus getting N features closer to existing. For once, I decided
against instant gratification :-).
-Karl
> 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:55:05 2005