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

[Linus Walleij <linus.walleij@linaro.org>]

On Thu, Apr 20, 2017 at 3:46 PM, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:

> Might just be good to chat a bit about when exactly a topic branch is
> called for, and when exactly merging through each separate tree is
> better. I get a bit the feeling that merging through separate trees is
> done to make sure platforms use all the infrastructure correctly
> (which is the topic below), but it seems like DT managed to get there
> without merging things stricly only through a DT tree.

What has been mentioned about Kconfig symbols being merged in
one place and then turned on in a merge commit is just part of it
really. To me the big pain is always API/file dependencies.

The typical case where we have to have a immutable topic branch
is when there is a new API (or just a header file really) added in one
patch and then a slew of patches need that API are sprinkled all over
the kernel, so they by necessity need to base on this nexus commit.

Essentially it happens when developers need an API from subsystem
A in place to do changes in subsystems B, C, D... Also they seldom have
patience to wait for a kernel cycle before making use of the API change,
instead one finger on the fastforward button at all times. (I don't blame them,
I am one of them.)

Typical cases:
<linux/mfd/*.h>
<dt-bindings/*.h>

I think Lee Jones could contribute to discussions around this, as he's
had the painful job to coordinate queue and quite a few of these hurdles
due to the nature of MFD as a connection nexus for misc.

One thing he does is queue an immutable topic branch, announce it and
let all affected subsystems pull it in, so that we (e.g. GPIO) can then
refactor or apply local fixes in "our" subsystem from that point, even during
the development cycle. It is pretty neat.

Yours,
Linus Walleij