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] [day] [month] [year] [list]

Message-ID: <Y0F5poxlesoIMa/+@matsya>
Date:   Sat, 8 Oct 2022 18:52:46 +0530
From:   Vinod Koul <vkoul@...nel.org>
To:     Linus Torvalds <torvalds@...ux-foundation.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 07-10-22, 16:22, Linus Torvalds wrote:
> 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.

Sorry I missed that.

> 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?

Thanks for letting me know. Sorry for the trouble this caused. Will
update my template to use the edited format you have applied.

-- 
~Vinod