linux-kernel - Re: [GIT PULL] random number generator fixes for 5.18-rc1

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, 31 Mar 2022 14:42:17 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     "Jason A. Donenfeld" <Jason@...c4.com>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PULL] random number generator fixes for 5.18-rc1

On Thu, Mar 31, 2022 at 2:24 PM Jason A. Donenfeld <Jason@...c4.com> wrote:
>
> PS: I noticed that for my previous pull request, in your merge commit, you
> replaced my numbered list with a bulleted list, and even went through the
> trouble of adjusting the irregular spacing caused by numbers >9. Impressed by
> this wild attention to detail, and imagining you clickity-clacking away in
> uemacs, I'll stick to hyphen-bullets now.

Heh. I just care fairly deeply about commit messages in general, and
my own in particular.

As a result, I try to make my merge messages be *somewhat* consistent
in layout, and with N different people sending my pull requests in
usually N+4 different formats, it means that I am very used to just
reformatting things so that *most* of my merges tend to follow one of
a few standard templates.

The standard templates I tend to aim for are

 (a) just regular quoted human-legible prose

 (b) bullet lists (sometimes with multiple levels of indentation)

 (c) a combination of the above: a human-readable introduction
followed by a bullet list.

 (d) Headers (eg "New drivers:", or "Fixes" vs "New code") with bullet lists

and if it's some other format I usually try to make it conform to one
of the above.

Along with just fixing typos and grammar as I find them.

And to make it even more exciting, sometimes part of it comes from the
pull request email, and another part from the signed tag.

But yeah, it does make it easier if the pull request already comes in
one of the normal formats. Then I generally just need to reflow things
for the common indentation.

But I do this _so_ much that I mostly don't even think about it any
more. I basically do it while reading the explanation. So while it
_has_ happened that I've complained about formatting, it must be
pretty egregious for me to really react.

Much more commonly I complain about people just not describing their
pull request well enough, not about some "you don't conform to the
usual formatting".

              Linus