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