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 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
