All of lore.kernel.org
 help / color / mirror / Atom feed
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

  reply	other threads:[~2016-09-01  8:18 UTC|newest]

Thread overview: 69+ 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 ` Keerthy
2016-06-20  8:43 ` [PATCH 1/9] regulator: tps65217: " Keerthy
2016-06-20  8:43   ` Keerthy
2016-06-21 19:08   ` Mark Brown
2016-06-22 10:14     ` Keerthy
2016-06-22 10:14       ` Keerthy
     [not found]       ` <576A64EA.4000607-l0cyMroinI0@public.gmane.org>
2016-06-22 10:16         ` Mark Brown
2016-06-22 10:16           ` Mark Brown
2016-06-22 10:26           ` Keerthy
2016-06-22 10:26             ` Keerthy
     [not found]             ` <576A67D9.6080707-l0cyMroinI0@public.gmane.org>
2016-06-23 10:26               ` Mark Brown
2016-06-23 10:26                 ` Mark Brown
     [not found]                 ` <20160623102634.GX28202-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2016-06-23 10:32                   ` Keerthy
2016-06-23 10:32                     ` Keerthy
2016-06-20  8:43 ` [PATCH 2/9] regulator: of: setup initial suspend state Keerthy
2016-06-20  8:43   ` Keerthy
     [not found]   ` <1466412218-5906-3-git-send-email-j-keerthy-l0cyMroinI0@public.gmane.org>
2016-06-22 15:29     ` Applied "regulator: of: setup initial suspend state" to the regulator tree Mark Brown
2016-06-22 15:29       ` Mark Brown
2016-06-20  8:43 ` [PATCH 3/9] regulator: tps65218: Enable suspend configuration Keerthy
2016-06-20  8:43   ` Keerthy
2016-06-27 17:00   ` Applied "regulator: tps65218: Enable suspend configuration" to the regulator tree Mark Brown
2016-06-27 17:00     ` 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-20  8:43   ` Keerthy
     [not found]   ` <1466412218-5906-5-git-send-email-j-keerthy-l0cyMroinI0@public.gmane.org>
2016-06-21 11:43     ` Tony Lindgren
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-20  8:43   ` 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-27 17:00     ` 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   ` Keerthy
2016-06-20  8:43 ` [PATCH 7/9] mfd: tps65218: add version check to the PMIC probe Keerthy
2016-06-20  8:43   ` Keerthy
2016-06-20  8:45   ` 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-10 20:04     ` Mark Brown
2016-08-31  8:31     ` Lee Jones
2016-08-31 11:41       ` Mark Brown
2016-08-31 11:41         ` Mark Brown
     [not found]         ` <20160831114105.GH3950-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2016-08-31 14:50           ` Lee Jones
2016-08-31 14:50             ` Lee Jones
2016-08-31 16:02             ` Mark Brown
2016-08-31 16:02               ` Mark Brown
     [not found]               ` <20160831160227.GC5967-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2016-09-01  8:23                 ` Lee Jones
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-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 10:17             ` Russell King - ARM Linux
     [not found]             ` <20160901101743.GB5783-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org>
2016-09-01 11:19               ` Lee Jones
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-06-20  8:43   ` 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-10 20:04     ` Mark Brown
2016-08-31 15:01     ` Lee Jones
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
2016-06-20  8:43   ` 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.