linux-kernel - Re: [GIT PULL]: SoundWire subsystem updates for v6.1-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]

Message-ID: <CAHk-=wjeQyCx-FGSaBckR+HgrMPYoHY2jwRq4J4JzpOczc+3fQ@mail.gmail.com>
Date:   Fri, 7 Oct 2022 16:22:06 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Vinod Koul <vkoul@...nel.org>
Cc:     Greg KH <gregkh@...uxfoundation.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PULL]: SoundWire subsystem updates for v6.1-rc1

On Fri, Oct 7, 2022 at 6:19 AM Vinod Koul <vkoul@...nel.org> wrote:
>
> soundwire updates for 6.1-rc1
>
>  - Pierre-Louis Bossart did another round of Intel driver cleanup to prepare
>    for future code reorg which is expected in next cycle
>  - Richard Fitzgerald provided bus unattach notifications processing during
>    re-enumeration along with Cadence driver updates for this.
>  - Srinivas Kandagatla added  Qualcomm driver updates to handle device0 status

So one of the things I do for merge messages is I try to make them all
_somewhat_ consistent.

That means that I now ended up editing all your explanations to match
the more common pattern, where when people credit the person doing the
work they put the name in parentheses after the explanation.

Partly that is just for consistency so that our logs read more like a
uniform body of work, but it also means that you don't need to add
pointless filler words to the explanations ("did", "provided",
"added").

So if you really want to mention peoples names (and it's ok, but it
does show up in the individual commits, so I'm not convinced it's
necessary in the merge commit overview of "what happened"), please try
to use that model.

And no, we're not really all _that_ consistent, and there's really a
few different merge commit patterns that we have.

Generally I try to make my editing fairly lightweight, but this was
just _so_ different from the normal merge commit log pattern that I
felt I needed to just edit a lot more than usual.

So a gentle query to maybe try to make them more in line with the
other patterns in the future to avoid extra work?

               Linus