lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+55aFzH+RrkebTvWYtvXOqMmQfrSy=coxt0ms9RGzN3kzxf4g@mail.gmail.com>
Date:   Sat, 26 Nov 2016 11:29:17 -0800
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Michael Ellerman <mpe@...erman.id.au>
Cc:     "Aneesh Kumar K. V" <aneesh.kumar@...ux.vnet.ibm.com>,
        Benjamin Herrenschmidt <benh@...nel.crashing.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        ppc-dev <linuxppc-dev@...ts.ozlabs.org>,
        Nick Piggin <npiggin@...il.com>, oohall@...il.com
Subject: Re: [GIT PULL] Please pull powerpc/linux.git powerpc-4.9-6 tag

On Sat, Nov 26, 2016 at 12:11 AM, Michael Ellerman <mpe@...erman.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.

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

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.

Again, when there are four commits, a "list of the details" pretty
much works. So the reason I react to _this_ pull request is mainly
that I have way more time to react to it during the late rc series
than I do earlier in the cycle..

                     Linus

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ