[Ksummit-discuss] [MAINTAINER TOPIC] Succession Planning: Is It time to Throw Linus Under a Bus?

Olof Johansson olof at lixom.net
Thu Sep 6 20:35:19 UTC 2018


On Thu, Sep 6, 2018 at 1:06 PM, Geert Uytterhoeven <geert at linux-m68k.org> wrote:
> On Thu, Sep 6, 2018 at 9:51 PM James Bottomley
> <James.Bottomley at hansenpartnership.com> wrote:
>> On Thu, 2018-09-06 at 21:47 +0200, Daniel Vetter wrote:
>> > On Thu, Sep 6, 2018 at 9:44 PM, James Bottomley
>> > <James.Bottomley at hansenpartnership.com> wrote:
>> > > Since our fearless leader apparently can't even remember the dates
>> > > of
>> > > the only conference he goes to, perhaps now might be a good time to
>> > > talk about how we'd run an orderly succession process (purely
>> > > theoretically, of course ...)
>> > >
>> > > I think a vote amongst the Maintainer Summit attendees might be the
>> > > way
>> > > to elect a new leader, but others probably have different ideas.
>> >
>> > Why I single leader?
>> >
>> > This group maintainer ship thing ... it  works.
>>
>> Well, lets talk about that.  I like the single leader model because it
>> doesn't lead to the cabal cult like the group maintainer model does in
>> BSD.  However, if we have a plan that can avoid that, I think it would
>> be a reasonable thing to try out.

Group maintainership can be dysfunctional, just like single
maintainers can be. And pockets of cabals exist already in some areas.

Worst case is probably selecting a single maintainer that turns out to
be a bad choice, and be stuck. With groups, it's easier to adjust if
needed.

I'd argue that having a group would be substantially more robust,
especially since the pool of people are likely to come from industry
and not just LF. We're all pretty good at leaving company politics and
influence out of our community work, but it's still desirable to have
a bit of balance in the higher maintainer roles.

>> I also note that group maintainership seems only to work for you in
>> DRM; most of the other subsystems seem to have single leader
>> hierarchical maintainership.
>
> Arm-soc has a triumvirate doing round-robin releases/pull-requests.

x86 is spread among several people as well (in fact, we originally
based arm-soc on their model but over time the practical
implementation has drifted somewhat).


-Olof


More information about the Ksummit-discuss mailing list