Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance

[Olof Johansson <olof@lixom.net>]

On Mon, Sep 10, 2018 at 8:31 AM, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> I need to split this up, otherwise I'll get lost on the different
> sub-topics. I'll start with the easy ones.

Agreed, I probably won't be able to keep up with this whole thread
this week due to $job, but a few stray comments:

> On Mon, Sep 10, 2018 at 4:53 PM, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
>>> Specific topics I'm interested in:
>>> - New experiments in group maintainership, and sharing lessons learned
>>> in general.
>>
>> I think that's good. But again, partly because these kinds of subjects
>> tend to devolve into too much of a generic overview, may I suggest
>> again trying to make things very concrete.
>>
>> For example, talk about the actual tools you use. Make it tangible. A
>> couple of years ago the ARM people talked about the way they split
>> their time to avoid stepping on each other (both in timezones, but
>> also in how they pass the baton around in general, in addition to
>> using branches).
>>
>> And yes, a lot of it probably ends up being "we didn't actually make
>> this official or write it up, but we worked enough together that we
>> ended up doing XYZ". That's fine. That's how real flows develop. With
>> discussion of what the problems were, and what this solved.
>>
>> In other words, make it down to earth. Not the "visionary keynote",
>> but the "this is the everyday flow".
>
> Yup, fully agreed. We don't need another overview over group
> maintainer ship. Also I don't think an update from arm-soc/tip or drm
> is interesting either. I think only if there's a new group/subsystem
> trying this out, with all the nitty-gritty details of "this totally
> blew up in our faces" and "this worked shockingly well" and "here we
> need to improve still, we're not happy" is what I'm looking for.
> Without those details there's nothing really to learn, beyond just
> rehashing one of the old discussions. I guess I should have put more
> emphasis on _new_ experiments :-)

I'm not interested in standing up and talking about how Arnd and I
handle things right now, but what I would be really interested in
talking about is where we still have chafing, where things don't
actually work great (Linus might be happy, but we're definitely in a
spot where we could simplify life for _us_ quite a bit).

I'm super excited to hear a bit about the _actual_ plans of gitlab
move. As mentioned, not a visionary keynote, but others also talking
about what they're looking at to fix their current pain points.


For us on arm-soc, we've gotten a bit better at reducing our overhead,
but the bulk of material coming in these days tends to be a no-op from
us (just figure out that it merges, that we have handshakes with any
external dependencies or shared branches, and pick it up). We have
some submaintainers who need more work, and we pay closer attention to
and have more feedback, but reducing the overhead for some of the
others by letting them cross-review and merge themselves would be
useful.

I'm also starting to get mildly annoyed by the single-patch pull
requests that we sometimes get. In some ways, applying patches are
easier, not harder. For those, the model where "cherry pick when
merging" in common code review tools would work really well.

> And if nothing changed, no new groups I think think we should table
> this right away.

I really want to talk about this, but if there isn't enough interest
from others, we could just do it in a hallway. But I think the topic
is on point for the maintainer summit.


-Olof