svn commit: r278718 - in stable/9: etc/rc.d sbin share/man/man4 share/mk sys/modules/geom tools/build/mk tools/build/options

Mon Feb 23 07:59:54 UTC 2015

On Feb 16, 2015, at 8:11, John Baldwin <jhb at freebsd.org> wrote:

> On Friday, February 13, 2015 09:36:17 PM Garrett Cooper wrote:
>> Author: ngie
>> Date: Fri Feb 13 21:36:16 2015
>> New Revision: 278718
>> URL: https://svnweb.freebsd.org/changeset/base/278718
>> 
>> Log:
>>  MFC r278717:
>> 
>>  r278717:
>> 
>>    MFC r277678:
>> 
>>    r277678:
>> 
>>      Add MK_CCD knob for building and installing ccd(4), ccdconfig, etc
>> 
>>      Sponsored by: EMC / Isilon Storage Division
> 
> I believe you are supposed to merge from HEAD to 9, not from 10 to 9.  

I try to do that where it makes sense. Merging and redoing some of the work I did going from head to head-1 increases the likelihood of error (especially with all of the build system refactoring that took place in the past year).

> But also, I find these log messages quite noisy.  I much prefer just:
> 
> MFC <head rev>:
> <original log message>
> 
> Where the <original log message> is not extra-indented but is formatted 
> similar to a normal commit.

I was doing that [subjectively] for readability, but that’s ok, I’ll take out the extra indentation.

> On a more general note, if I'm merging a change with several followup fixes, I 
> 1) always merge the entire batch of changes so as not to leave stable/ in a 
> broken state (most folks also do this), and 2) I don't cut and paste all N 
> logs verbatim.  This tends to be very hard to read.  Instead, I do 'MFC <list 
> of head revs>' and then use a brief summary of the change being merged.  Often 
> this means using the log message of the first change (which introduces the new 
> feature and explains it) but omitting short descriptions of specific bugs 
> fixed (which aren't very useful to someone reading the stable log message as 
> the commit in question is introducing the needed feature in its fixed state.)
> 
> This does require a bit more effort editorial wise, but I think it results in 
> commit logs for stable that are more readable.

Sure.

I wish that there was a set format for this. All of this is scripted for me, so merging is a trivial task — it’s just a bit confusing when I have 5 different people telling me my MFC message is wrong, but oh well… it’s just a script. Lol.

Thanks :),
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freebsd.org/pipermail/svn-src-stable-9/attachments/20150222/6dffc08c/attachment.sig>