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

[Olof Johansson <olof@lixom.net>]

On Sat, Apr 29, 2017 at 2:00 PM, Daniel Vetter <daniel.vetter@ffwll.ch> 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.

As mentioned already, we've seen too many messes caused by multiple
people stepping on each other. When you merge a mixed-contents branch
through another subsystem you have to gamble on anyone else not
touching anything near it.

Worst case possible is refactorings of code made by people at the same
time, with the almost-as-bad-case of one side refactoring, the other
one adding something new. And given how refactoring-happy DRM is, I'm
extremely hesitant to see ARM contents merged through there.

Another reason for that is that it's pretty common to have for example
media and graphics handled by separate teams from main platform code
(both in corporate land as well as on the community side). Having two
separate teams work on the same piece of code means that even though
_you_ say it's OK to merge through a different tree, the platform
maintainer on the other team might have different plans for that code.

Yes, there's some overhead in dealing with this. Most of it is pushed
down to the per-platform level, so there's no need to coordinate all
the way up the maintainer path in many cases. Main exception is
usually new contributors/platforms where we keep an extra eye on
things as new people get used to their roles, build up experience,
etc.


-Olof