Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

[Mark Brown <broonie@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 1740 bytes --]

On Sat, Apr 29, 2017 at 02:39:31PM -0700, James Bottomley wrote:
> On Sat, 2017-04-29 at 23:00 +0200, Daniel Vetter wrote:
> > On Tue, Apr 25, 2017 at 11:10 AM, Lee Jones <lee.jones@linaro.org>

> > > Although common place, immutable branches are still treated as the
> > > last resort.  If patches can be taken via their respective 
> > > subsystem trees without fear of disruption, they are.  Contributors 
> > > often attempt to have their *new* cross-subsystem functionality 
> > > taken in via a single tree (requiring an immutable branch), purely 
> > > because it's convenient and the merge-time becomes deterministic, 
> > > but we do not allow that unless there are hard/unavoidable build
> > > -time dependencies.

> > Honest question, why exactly?

[Snip a bunch of good reasons from James]

> > At a quick ignorant glance this seems to trade contributor time
> > against maintainer time, which in my opinion means you should ramp up
> > your maintainer training and mentoring to have much more maintainer
> > time available and make contributing to upstream more attractive. But
> > drm != other subsystems, I'd like to hear more of why you picked this
> > tradeoff.

> It's not just maintainer time ... taking patches outside your subsystem
> should always have a good reason because it's not just a
> training/tooling issue; you're potentially impacting some other
> subsystem by this action.

The other thing is that no matter how good the maintainers are at
handling cross tree stuff there's always going to be some cost to the
submitter even if it's just delays as the maintainers talk to each
other.  The less coordination is needed the more chance there is that
things will go smoothly.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]