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

[Thomas Gleixner <tglx@linutronix.de>]

On Thu, 13 Sep 2018, Jani Nikula wrote:
> On Thu, 13 Sep 2018, Alexandre Belloni <alexandre.belloni@bootlin.com> wrote:
> > On 13/09/2018 14:08:11+0200, Maxime Ripard wrote:
> >> All the knowledge they built, experience they got (including at
> >> reviewing) is gone, possibly forever, and there's no one to pick up
> >> the subsystem, and the code is left to rot.
> >
> > And this is almost the same for the DRM core where Daniel is by far the
> > top contributor.
> 
> Except he's no longer a maintainer in either DRM or i915. Checking the
> stats against current MAINTAINERS will paint you a different picture.
> 
> And that brings us to another important point: Group maintainership
> allows for easier onboarding of new maintainers, and easier retirement
> of old ones. We've changed several maintainers for both the drm-misc
> tree and i915 since we've switched to group maintainership, and there
> hasn't been noticeable bumps in the road. Mostly just business as
> usual. Being a maintainer doesn't have to be for life, and you don't
> have to burn out and rage quit one fine day and leave everything in
> ruins behind you as you go.
> 
> I'm not saying one size fits all, and I'm not saying it's easy to find
> more maintainers. But it's certainly much *much* easier to find a new
> co-maintainer to a team of two or three than a new solo maintainer.

You are sounding like DRM invented group maintainership and needs to go
advertising it now as the best invention since sliced bread.

It's been in practice since 2007 when the tip tree started with 3
maintainers. It was then adopted by ARM-SoC and Linus recommended it as a
good model way before DRM went that road.

We all know that group maintainership is a good thing, but we also know
that it's not working for all subsystems and that it's not always easy to
find matching co-maintainers. Most maintainers, if not all, would be happy
to have a competent, trusted and interested co-maintainer. So it's not that
they need to be educated on that.

Group maintainership is not the Panacea. So please stop the prayer wheel
and come up with solutions which address identifed indivudual problems. Not
having group maintainership is for some subsystems the least of their
worries. And as a member of the first official maintainer group in the
kernel I can assure you that group maintainership is not making all other
and potentially more dangerous problems magically go away.

Thanks,

	tglx