From: Lee Jones <lee.jones@linaro.org>
To: Russell King - ARM Linux <linux@armlinux.org.uk>
Cc: Mark Brown <broonie@kernel.org>, Tero Kristo <t-kristo@ti.com>,
Dave Gerlach <d-gerlach@ti.com>, Keerthy <j-keerthy@ti.com>,
tony@atomide.com, devicetree@vger.kernel.org,
linux-omap@vger.kernel.org, linux-kernel@vger.kernel.org,
russ.dill@ti.com, robh+dt@kernel.org, mark.rutland@arm.com
Subject: Re: Applied "mfd: tps65218: add version check to the PMIC probe" to the regulator tree
Date: Thu, 1 Sep 2016 09:18:34 +0100 [thread overview]
Message-ID: <20160901081834.GE4921@dell> (raw)
In-Reply-To: <20160831175701.GA5783@n2100.arm.linux.org.uk>
On Wed, 31 Aug 2016, Russell King - ARM Linux wrote:
> 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.
It's not up to submitters which repo patches get applied to. They are
free to make a verbal (written) request and if it's justified then we
can choose to agree to it or not. For instance, a submitter is more
likely to know if a dependency was recently taken in via a particular
tree than a Maintainer, since it's almost impossible to keep track
each and every patch and all it's possible dependants.
I personally review/accept patches based solely on the subsystem(s)
touched and the actions of particular Maintainers, knowing firstly how
they operate. Actioning patches based on whether a contributor uses
the To: or Cc: lines seems very fragile and prone to unnecessary
complications.
> 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!)
I use the Mutt's default configuration for 'reply-to-all' in all
cases. I really don't have time to manually reorganise something as
trivial as To: and Cc: lines. I find them irrelevant in this
setting. Any time spent on trivial activities such as these adds
further delay to patch-reviews. Some of us have day jobs too you
know. ;)
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
next prev parent reply other threads:[~2016-09-01 8:16 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-20 8:43 [PATCH 0/9] regulator: Enable suspend configuration Keerthy
2016-06-20 8:43 ` [PATCH 1/9] regulator: tps65217: " Keerthy
2016-06-21 19:08 ` Mark Brown
2016-06-22 10:14 ` Keerthy
2016-06-22 10:16 ` Mark Brown
2016-06-22 10:26 ` Keerthy
2016-06-23 10:26 ` Mark Brown
2016-06-23 10:32 ` Keerthy
2016-06-20 8:43 ` [PATCH 2/9] regulator: of: setup initial suspend state Keerthy
2016-06-22 15:29 ` Applied "regulator: of: setup initial suspend state" to the regulator tree Mark Brown
2016-06-20 8:43 ` [PATCH 3/9] regulator: tps65218: Enable suspend configuration Keerthy
2016-06-27 17:00 ` Applied "regulator: tps65218: Enable suspend configuration" to the regulator tree Mark Brown
2016-06-20 8:43 ` [PATCH 4/9] ARM: dts: AM437X-GP-EVM: AM437X-SK-EVM: Make dcdc3 dcdc5 and dcdc6 enable during suspend Keerthy
2016-06-21 11:43 ` Tony Lindgren
2016-06-21 11:46 ` Tony Lindgren
2016-06-20 8:43 ` [PATCH 5/9] regulator: tps65218: force set power-up/down strobe to 3 for dcdc3 Keerthy
2016-06-27 17:00 ` Applied "regulator: tps65218: force set power-up/down strobe to 3 for dcdc3" to the regulator tree Mark Brown
2016-06-20 8:43 ` [PATCH 6/9] ARM: dts: am437x-gp-evm: disable DDR regulator in rtc-only/poweroff mode Keerthy
2016-06-20 8:43 ` [PATCH 7/9] mfd: tps65218: add version check to the PMIC probe Keerthy
2016-06-20 8:45 ` Keerthy
2016-08-10 20:04 ` Applied "mfd: tps65218: add version check to the PMIC probe" to the regulator tree Mark Brown
2016-08-31 8:31 ` Lee Jones
2016-08-31 11:41 ` Mark Brown
2016-08-31 14:50 ` Lee Jones
2016-08-31 16:02 ` Mark Brown
2016-09-01 8:23 ` Lee Jones
2016-09-01 8:54 ` Mark Brown
2016-09-01 9:34 ` Lee Jones
2016-08-31 17:57 ` Russell King - ARM Linux
2016-09-01 8:18 ` Lee Jones [this message]
2016-09-01 10:17 ` Russell King - ARM Linux
2016-09-01 11:19 ` Lee Jones
2016-09-01 14:23 ` Russell King - ARM Linux
2016-09-01 14:53 ` Lee Jones
2016-06-20 8:43 ` [PATCH 8/9] regulator: tps65218: do not disable DCDC3 during poweroff on broken PMICs Keerthy
2016-08-10 20:04 ` Applied "regulator: tps65218: do not disable DCDC3 during poweroff on broken PMICs" to the regulator tree Mark Brown
2016-08-31 15:01 ` Lee Jones
2016-09-01 10:06 ` Mark Brown
2016-06-20 8:43 ` [PATCH 9/9] ARM: dts: am437x-sk-evm: disable DDR regulator in rtc-only/poweroff mode Keerthy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160901081834.GE4921@dell \
--to=lee.jones@linaro.org \
--cc=broonie@kernel.org \
--cc=d-gerlach@ti.com \
--cc=devicetree@vger.kernel.org \
--cc=j-keerthy@ti.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=mark.rutland@arm.com \
--cc=robh+dt@kernel.org \
--cc=russ.dill@ti.com \
--cc=t-kristo@ti.com \
--cc=tony@atomide.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).