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

[Lee Jones <lee.jones@linaro.org>]

On Sat, 29 Apr 2017, 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?
> 
> 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 looks like James et. al. have provided some pretty good technical
reasons as to why taking patches via their associated subsystem repos
is *always* preferred, so I will not labour this point.  However I
will provide a frank answer to your trading Maintainer for Contributor
time query.

To be candid, you're right we do that, and it's exactly what we
should be doing.  There are a couple of reasons for this:

The first is a simple matter of time related mathematics.  Taking an
average over the past 10 releases, MFD and Backlight had ~30 unique
submitters per release.  If even some of them managed to get
themselves into habits which cost me more time than it already does
to Maintain the subsystems, then either the Maintainership or my
employment role would be negatively impacted.  I view it better to
cost each Contributor 30 mins, than it to cost me 30 mins multiplied
by the amount of Contributors. Moreover, most Contributors are doing
so *as part* of their employment role, where-as myself and a great
many other Maintainers are operating *as well as*, or outside of
ours.

Secondly, this is about Contributor training and the encouragement of
good practices from the outset; patch separation, expert reviews,
conflict mitigation, bisection preservation, etc etc.  If we train and
arm the Contributors of today, we inherently encourage the Maintainers
of tomorrow.

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