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

[James Bottomley <James.Bottomley@HansenPartnership.com>]

On Sat, 2017-04-29 at 23:00 +0200, Daniel Vetter wrote:
> [Back from a bit of vacation, so I'm just jumping into the middle of
> the cross-subsystem/invariant topic branch discussion. I read all the
> other mails, but this seems most relevant.]
> 
> On Tue, Apr 25, 2017 at 11:10 AM, Lee Jones <lee.jones@linaro.org>
> wrote:
> > 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?

Because if you take a patch for, say SCSI, through your tree it
potentially becomes a big pain for everyone if we pick up a conflict. 
 The conflict isn't seen until linux-next finds it because the
conflicting patch is in your tree not mine (and SCSI contributors
mostly build against the SCSI tree) then Stephen has to come up with a
merge and we have to validate it and send it on to Linus as a
recommendation at merge window time.

Another good reason for not taking patches to subsystems outside yours
are that you're not necessarily an expert in whatever subsystem it is,
so a patch would get a better review cycle going through the correct
subsystem tree.

There are good reasons to take on this pain, like the conflicting patch
depends on something else that's in your tree but not in mine, so
there's no clean way to split it up and thus it makes sense to take it
through your tree and just handle the conflicts as they arise but
absent that the rule should be that patches to a subsystem go through
its tree.

> 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.

James