Message-ID: <20160901111918.GJ4921@dell>
Date:   Thu, 1 Sep 2016 12:19:18 +0100
From:   Lee Jones <lee.jones@...aro.org>
To:     Russell King - ARM Linux <linux@...linux.org.uk>
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 Thu, 01 Sep 2016, Russell King - ARM Linux wrote:

> On Thu, Sep 01, 2016 at 09:18:34AM +0100, Lee Jones wrote:
> > 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.
> 
> Wrong.  It's up to submitters to send TO the person who they want to
> apply the patch - that's how it's always worked.
> 
> What's become broken is this idea of "I absolutely own this area of the
> kernel, all patches _must_ come through me."  That's never been the case.
> 
> There may be a good reason why the submitter doesn't want the normal
> maintainer of an area of the kernel to take the patch, in which case
> the submitter has every right to decide who should take their patch.
> The wrong maintainer taking the patch can screw up the submitters
> workflow, cause additional conflicts, or break dependencies.  The
> submitter is the best person to decide who should apply their change.

I agree that the submitter is the best person to provide a compelling
case to re-route a patch's normal submission path.  I disagree that
they have the final say.  I've had a bunch of requests asking if a
patch can go in via a different repository due to convenience i.e.
their feature will magically start working once the set lands.  Myself
and the all of the Maintainers I regularly work with vehemently push
back on that, and insist the only 2 cases which will be considered are
a) to prevent merge-conflicts and b) in the case of a *build*
dependency.  If neither of those boxes are ticked, then we separate
the set and apply the patches pertaining to the subsystems we each
look maintain.

In the acceptable cases above, if I am the *lucky* person to route the
patches to Mainline (which 9 out of 10 times I am), I religiously send
pull-requests to the other Maintainers, so they can continue to avoid
merge conflicts, both in their own trees and in Linus' during the
merge-window.  If patches go through another tree, I usually insist
on an immutable branch to pull from, for the same reasons stated.

> > 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. ;)
> 
> Exactly - some of us don't have a lot of time, and some of us don't
> read messages that aren't sent either To or Cc'd to us.  Some of us
> also place messages that are Cc'd at a _much_ lower priority than
> those which are sent To them.

I can live with that.

So far I have not been inhibited by this, AFAIK.

> If people want me to take some action with their message, they had
> better put me in the To: line and _not_ the Cc, otherwise they're
> risking me ignoring them for a long time.

I'm not sure many people work like that, sending or receiving.  In my
case I deal with every mail I receive, firstly by brain grepping --
skimming over the subject headers for mails I consider urgent.
Everything else gets marked as 'important' and is dealt with
chronologically.  No where in my workflow to do filter by, or consider
To: and Cc: fields.  That just sounds like too much effort.

Again, sorry if that messes with your workflow, truly, but I have more
important things to focus on.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Powered by blists - more mailing lists