From: Michael Ellerman <mpe@ellerman.id.au>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: "Aneesh Kumar K. V" <aneesh.kumar@linux.vnet.ibm.com>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
ppc-dev <linuxppc-dev@lists.ozlabs.org>,
Nick Piggin <npiggin@gmail.com>,
oohall@gmail.com
Subject: Re: [GIT PULL] Please pull powerpc/linux.git powerpc-4.9-6 tag
Date: Mon, 28 Nov 2016 20:46:40 +1100 [thread overview]
Message-ID: <87vav8q6m7.fsf@concordia.ellerman.id.au> (raw)
In-Reply-To: <CA+55aFzH+RrkebTvWYtvXOqMmQfrSy=coxt0ms9RGzN3kzxf4g@mail.gmail.com>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Sat, Nov 26, 2016 at 12:11 AM, Michael Ellerman <mpe@ellerman.id.au> wrote:
>>
>> powerpc fixes for 4.9 #6
>>
>> Fixes marked for stable:
>> - Set missing wakeup bit in LPCR on POWER9 (Benjamin Herrenschmidt)
>> - Fix the early OPAL console wrappers (Oliver O'Halloran)
>> - Fixup kernel read only mapping (Aneesh Kumar K.V)
>>
>> Fixes for code merged this cycle:
>> - Fix missing CRCs, add more asm-prototypes.h declarations (Nicholas Piggin)
>
> Pulled, but I wanted to talk about your merge "summary".
>
> Your merge summaries seem to be entirely automatically generated,
> which makes them less than great. I can see all that stuff in the git
> tree already, just formatting it differently isn't all that useful.
OK. The starting point is obviously an automatically generated list of
commits, but I have been editing that a fair bit to drop boring commits
and combine multiple commits into a single line, and then sort it by
topic area etc.
But obviously I'm not editing it enough, so I'll try to summarise it
much more heavily.
> For something like this late-rc pull when there are only a couple of
> commits, the end result actually ends up looking almost like a summary
> and all I did was remove the names that don't add to the description
> (and are in the git commits).
I actually do like to include the names, just to give people a bit of
acknowledgment in the pull request, but I can drop them if you prefer.
Or maybe I'll just include a credits section at the bottom of the tag
with everyone's name once, and you can drop that from the commit?
> For some of the bigger pull requests, the summary is almost anything
> but, and the only real value-add is the grouping by subject area.
>
> I really prefer a _summary_. Something that is human-legible. So that
> when people read the merge commit log, they get an overview of what
> changed, not a list of the details.
Right.
cheers
prev parent reply other threads:[~2016-11-28 9:46 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-26 8:11 Michael Ellerman
2016-11-26 19:29 ` Linus Torvalds
2016-11-28 9:46 ` Michael Ellerman [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87vav8q6m7.fsf@concordia.ellerman.id.au \
--to=mpe@ellerman.id.au \
--cc=aneesh.kumar@linux.vnet.ibm.com \
--cc=benh@kernel.crashing.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=npiggin@gmail.com \
--cc=oohall@gmail.com \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®