linux-kernel - Re: [PATCH 1/2] Revert "ASoC: hdmi-codec: re-introduce mutex locking"

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: <20191023184640.GN5723@sirena.co.uk>
Date:   Wed, 23 Oct 2019 19:46:40 +0100
From:   Mark Brown <broonie@...nel.org>
To:     Russell King - ARM Linux admin <linux@...linux.org.uk>
Cc:     Jerome Brunet <jbrunet@...libre.com>,
        Liam Girdwood <lgirdwood@...il.com>,
        alsa-devel@...a-project.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] Revert "ASoC: hdmi-codec: re-introduce mutex locking"

On Wed, Oct 23, 2019 at 07:26:18PM +0100, Russell King - ARM Linux admin wrote:

> If you look at the git log for reverted commits, the vast majority
> of them follow _this_ style.  From 5.3 back to the start of current
> git history, there are 3665 commits with "Revert" in their subject
> line, 3050 of those start with "Revert" with no subsystem prefix.

That's assuming that all reverts have Revert in their subject line of
course!

> It seems that there are a small number of subsystems that want
> something different, ASoC included.  That will be an ongoing problem,
> people won't remember which want it when the majority don't.

> Maybe the revert format should be standardised in some manner?

My general thought on this is that reverts are commits like any other
and that the documentation for how you're supposed to do commit messages
also applies to them, might be worth a note though as I do see people
not writing a commit log at all for them sometimes.

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)