On Thu, Sep 13, 2018 at 1:07 PM Thomas Gleixner <tglx@linutronix.de> wrote:

> 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.
>

I had to read the thread twice to see if I could understand how you arrived
to this conclusion.

I really didn't see anyone claiming to be the inventor of group
maintainership.

And this is really not the point of what Daniel is proposing here.


> 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.
>

Good for you!

Well, it actually might be good for everyone if you have lessons learned
for sharing as Daniel proposed:

"- New experiments in group maintainership, and sharing lessons learned
in general."


>
> 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.
>

What I see on Daniel's email is not an education proposal, but to just talk
and share
experience. He is "open to anything else really on the larger topic of
community mangement."


>
> 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.
>

But if there's time to discuss I don't know why they should be exclusive
things...

Thanks,
Rodrigo.


> Thanks,
>
>         tglx
>
> _______________________________________________
> Ksummit-discuss mailing list
> Ksummit-discuss@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
>