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]
Date:   Thu, 13 Oct 2016 17:21:40 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Bjorn Helgaas <helgaas@...nel.org>
Cc:     "linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Thomas Petazzoni <thomas.petazzoni@...e-electrons.com>,
        Dan Carpenter <dan.carpenter@...cle.com>,
        Kishon Vijay Abraham I <kishon@...com>
Subject: Re: [GIT PULL] PCI changes for v4.9

On Thu, Oct 13, 2016 at 4:48 PM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> Ugh:
>
> Your "summary" is actually less legible than the shortlog, and looks
> entirely auto-generated.
>
> That's against the whole point of having a summary for a pull request.
>
> Please tell me what changed, don't auto-generate pointless unreadable crud. Ok?

I wrote some kind of summary based on actually (hopefully) intelligent
culling of relevant information instead of just bunching up together
automated data.

It may not be complete, but it's the kind of "what does this merge
actually _merge_" information that is useful. Please do something like
this in the future rather than the automated illegible mush:

 "Summary:

   - use local struct device pointers in many host bridge drivers for
     clarity

   - remove unused platform data

   - use generic DesignWare accessors

   - misc cleanups: remove redundant structure entries and re-order
     structure members to put comon generic fields first etc"

See? Humans can read that and get an idea of what is going on. It
would be even better if it had a few more lines about why those things
matter, but as is, it's much better than that that tag contained.

But the reason I want the maintainer to write this is that I'm lazy.

No, wait, it's really because you are supposed to know the high-level
detail and be able to really notice what is relevant. I just went by
looking for patterns in the shortlog, doing silly things like

   git shortlog ..FETCH_HEAD --no-merges | cut -d: -f3- | sort | uniq
-c | sort -n

to get a feel for what you had done. But because I don't know the
code, maybe I missed some really important change, or
mis-characterized it somehow, or whatever.

Which is why I want the pull requests to contain the kind of relevant
information on what the hell is going on. Not just a "this is all that
happened" munged shortlog in a slightly different format.

                Linus

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ