svn commit: r196746 - in stable/8/sys: . amd64/include/xen cddl/contrib/opensolaris contrib/dev/acpica contrib/pf dev/usb dev/usb/input dev/xen/xenpci

[Sean C. Farley]

On Wed, 2 Sep 2009, Ken Smith wrote:

> On Wed, 2009-09-02 at 08:14 -0700, Doug Barton wrote:
>> That said, for RELENG_8 commits during the freeze re@ did ask in one 
>> of their many messages about commit approvals to paste the complete 
>> commit message in the MFC. So, bad Alfred, no cookie. :)
>
> Just for clarification...  We ask that you send your complete 
> *proposed commit message* in your *approval request*.  We didn't say 
> that your commit message needs to include all of the text from the 
> commit to head.
>
> So, bad Doug, no cookie.  :-)
>
> FWIW my preference is, as usual, somewhere in between the two 
> extremes.  Duplicating a lengthy commit message in a merge is overkill 
> but in those cases a short (one sentence max) summary of what changed 
> being in the merge commit message is helpful.  For example when 
> looking through the commits for release notes fodder it can help.  It 
> also helps people who take the peer review of commits being done 
> seriously to get the warm fuzzy feeling that the merge wasn't an 
> accidental mis-merge (by seeing that the code seems to match the brief 
> description).

Personally, I like to include the entire message to prevent having to 
scan the logs for the original commit(s), however, an alternative would 
be to have the MFC include a URL to the original commit.  Two options 
would be:
1. Automatic insertion into log message with a Subversion hook which
    adds a URL from scanning a special code in the MFC message (MFC
    r12345,12346-12349).  Of course, this takes more initial setup and
    education for committers (at least me :)) to use it correctly.
2. Committer can use a special base URL that is agreed to never change.
    This would make it easier to find the original log message without
    having to scan for it.

Sean
-- 
scf at FreeBSD.org