linux-kernel - Re: Applied "mfd: tps65218: add version check to the PMIC probe" to the regulator tree

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:   Wed, 31 Aug 2016 18:57:01 +0100
From:   Russell King - ARM Linux <linux@...linux.org.uk>
To:     Lee Jones <lee.jones@...aro.org>
Cc:     Mark Brown <broonie@...nel.org>, Tero Kristo <t-kristo@...com>,
        Dave Gerlach <d-gerlach@...com>, Keerthy <j-keerthy@...com>,
        tony@...mide.com, devicetree@...r.kernel.org,
        linux-omap@...r.kernel.org, linux-kernel@...r.kernel.org,
        russ.dill@...com, robh+dt@...nel.org, mark.rutland@....com
Subject: Re: Applied "mfd: tps65218: add version check to the PMIC probe" to
 the regulator tree

On Wed, Aug 31, 2016 at 09:31:14AM +0100, Lee Jones wrote:
> On Wed, 10 Aug 2016, Mark Brown wrote:
> 
> > The patch
> > 
> >    mfd: tps65218: add version check to the PMIC probe
> 
> Why did you take this patch?

I think folk need to start to understand the purpose of the To: and Cc:
lines in emails.

To: means you're sending the message _to_ the recipient, expecting them
to be the _primary_ receiver of the message, and to _process_ the message
in some way.  In the case of a patch, that may be applying the change.

Cc: means you're providing the recipient with a copy of the message, "for
their information" and you're not expecting them to take action.

If you think that there's no difference between To: and Cc: then ask
yourself this question: what's the point of having the two headers,
why not list all recipients under one single header.

Mark was in the To: line, therefore it is perfectly reasonable for him
to apply the patch when it gets acked, since the original author sent
it _TO_ Mark implicitly asking him to apply it.

If you have a problem with that, then you need to say something in
reply to the patch, or you need to instruct folk who send patches for
bits of your subsystem not to place others in the To: field who may
pick up the patch.

However, there is a tendency with some people's mailers (including
yours) which keeps the recipients of the To: and Cc: from the message
being replied to, and copies them to the reply as-is.  That totally
screws up the meaning of the To: and Cc: headers, and is really
really really really annoying for people who are in the To: field
but who aren't being asked to do anything in the replies.  (Fix your
bloody mailer not to do this please!)

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.