From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 1A010CAB for ; Thu, 13 Sep 2018 23:03:18 +0000 (UTC) Received: from mail-wr1-f50.google.com (mail-wr1-f50.google.com [209.85.221.50]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id EAB747FB for ; Thu, 13 Sep 2018 23:03:16 +0000 (UTC) Received: by mail-wr1-f50.google.com with SMTP id a108-v6so8416328wrc.13 for ; Thu, 13 Sep 2018 16:03:16 -0700 (PDT) MIME-Version: 1.0 References: <8412864.7ztUKcXNNC@avalon> <2019489.6joTqyUi4Z@avalon> <20180911124423.GM2494@piout.net> <20180912182343.GI2760@piout.net> <20180913120811.oilaweiun3z4l5wo@flea> <20180913125723.GC14988@piout.net> <87a7olzd7s.fsf@intel.com> In-Reply-To: From: Rodrigo Vivi Date: Thu, 13 Sep 2018 16:02:57 -0700 Message-ID: To: Thomas Gleixner Content-Type: multipart/alternative; boundary="00000000000041b47b0575c8b688" Cc: ksummit-discuss@lists.linuxfoundation.org Subject: Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , --00000000000041b47b0575c8b688 Content-Type: text/plain; charset="UTF-8" On Thu, Sep 13, 2018 at 1:07 PM Thomas Gleixner wrote: > On Thu, 13 Sep 2018, Jani Nikula wrote: > > On Thu, 13 Sep 2018, Alexandre Belloni > 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 > --00000000000041b47b0575c8b688 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


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&g= t; 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 f= ar 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.<= br> >
> 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-mi= sc
> tree and i915 since we've switched to group maintainership, and th= ere
> hasn't been noticeable bumps in the road. Mostly just business as<= br> > 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 unde= rstand how you arrived to this conclusion.

I reall= y 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 f= or everyone if you have lessons learned for sharing as Daniel proposed:

"- New experiments in group maintainership, and = sharing lessons learned
in general."
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
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 e= asy to
find matching co-maintainers. Most maintainers, if not all, would be happy<= br> 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 com= munity mangement."
=C2=A0

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,
<= div>Rodrigo.


Thanks,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 tglx

_______________________________________________
Ksummit-discuss mailing list
Ksummit-discuss@lists.linuxfoundation.org
https://lists.linuxfoundation.org/= mailman/listinfo/ksummit-discuss
--00000000000041b47b0575c8b688--