Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 02 Sep 2009 08:57:37 -0700
From:      Doug Barton <dougb@FreeBSD.org>
To:        Ken Smith <kensmith@cse.Buffalo.EDU>
Cc:        remko@elvandar.org, svn-src-stable@FreeBSD.org, svn-src-all@FreeBSD.org, Alfred Perlstein <alfred@FreeBSD.org>, src-committers@FreeBSD.org, svn-src-stable-8@FreeBSD.org
Subject:   Re: 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
Message-ID:  <4A9E95F1.9070309@FreeBSD.org>
In-Reply-To: <1251905775.24711.32.camel@bauer.cse.buffalo.edu>
References:  <200909020212.n822C7Il078379@svn.freebsd.org>	 <8497dc1520e5fe6b2b3727d5fb92f358.squirrel@www.jr-hosting.nl>	 <4A9E8BBE.9060000@FreeBSD.org> <1251905775.24711.32.camel@bauer.cse.buffalo.edu>

next in thread | previous in thread | raw e-mail | index | archive | help
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.  :-)

-------- Original Message --------
Subject: Repost: approval request and merge guidelines during release
cycle
Date: Sun, 16 Aug 2009 10:29:58 +0100 (BST)
From: Robert Watson <rwatson@FreeBSD.org>
To: developers@FreeBSD.org

[...]

5. When committing the merge, include the original revision number
(rXXXXXX) and a copy of the original commit message in the merge
commit message.

But you're the boss, so whatever you say goes. :) (I would like my
cookie back though.)

> 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).

Seriously though, I agree with you, and will be happy to continue
complying with this policy going forward. :)


Doug

-- 

    This .signature sanitized for your protection




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4A9E95F1.9070309>