[Bug binutils/14768] Checklist: Binutils Migration To Git

[amodra at gmail dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=14768

Alan Modra <amodra at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |amodra at gmail dot com

--- Comment #11 from Alan Modra <amodra at gmail dot com> ---
Can I suggest a commit log policy change when we switch to git?  Something
like:

The commit log should generally consist of the subject line in your mailing
list patch submission, followed by the url of the patch, the explanatory text
you wrote in that email, and optionally, the ChangeLog entry for your patch. 
Do *not* include the actual patch in the log message!  For example, here is one
I wrote for a glibc patch.

    PowerPC SIGSTKSZ
    http://sourceware.org/ml/libc-alpha/2013-08/msg00093.html

    This copies the sparc version of sigstack.h, which gives powerpc
     #define MINSIGSTKSZ     4096
     #define SIGSTKSZ        16384

    Before the VSX changes, struct rt_sigframe size was 1920 plus 128 for
    __SIGNAL_FRAMESIZE giving ppc64 exactly the default MINSIGSTKSZ of
    2048.

    After VSX, ucontext increased by 256 bytes.  Oops, we're over
    MINSIGSTKSZ, so powerpc has been using the wrong value for quite a
    while.  Add another ucontext for TM and rt_sigframe is now at 3872,
    giving actual MINSIGSTKSZ of 4000.

    The glibc testcase that I was looking at was tst-cancel21, which
    allocates 2*SIGSTKSZ (not because the test is trying to be
    conservative, but because the test actually has nested signal stack
    frames).  We blew the allocation by 48 bytes when using current
    mainline gcc to compile glibc (le ppc64).

    The required stack depth in _dl_lookup_symbol_x from the top of the
    next signal frame was 10944 bytes.  I guess you'd want to add 288 to
    that, implying an actual SIGSTKSZ of 11232.

The subject should be on a line by itself and not exceed 75 characters. You
should have chosen a subject that was a reasonable summary of your patch when
writing your patch submission.  This helps the relevant maintainer notice your
patch, and helps people searching for a bug fix.  We ask for this in the commit
log too, because a number of tools display the first line of git commit logs.

The url of your patch allows people to easily find discussion related to your
patch.

The explanatory text is there in the commit log to aid people working with the
sources offline.  The ChangeLog entry in the commit log is optional except when
you did not include explanatory text in your patch submission, which might be
reasonable if the ChangeLog entry is self-explanatory.

There are of course exceptions to these rules.  For example, a single line
commit log saying "regenerate configure" is acceptable if that is all you are
doing.

-- 
You are receiving this mail because:
You are on the CC list for the bug.