Re: [Ksummit-discuss] "Maintainer summit" invitation discussion

From: Linus Torvalds <torvalds@linux-foundation.org>
To: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Rom Lemarchand <romlem@google.com>,
	ksummit <ksummit-discuss@lists.linuxfoundation.org>,
	Dave Airlie <airlied@linux.ie>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"Nikula, Jani" <jani.nikula@linux.intel.com>,
	Ingo Molnar <mingo@kernel.org>,
	Doug Ledford <dledford@redhat.com>,
	Sean Paul <seanpaul@chromium.org>,
	David Miller <davem@davemloft.net>
Subject: Re: [Ksummit-discuss] "Maintainer summit" invitation discussion
Date: Tue, 18 Apr 2017 13:56:21 -0700	[thread overview]
Message-ID: <CA+55aFxhK=h-wr8kFf42fXFHh-Dsn7QNiFWt+Kcr0umG4k3gQw@mail.gmail.com> (raw)
In-Reply-To: <CAKMK7uE+E0RAB7z3zhtKn5tj45g_0PsLnNrGwJOxGJzUyqos8g@mail.gmail.com>

On Tue, Apr 18, 2017 at 1:38 PM, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
>
> Depending what we talk about it might be useful to invite Sean Paul
> and/or Jani Nikula as drm-misc co-maintainers (which really is the drm
> core + subsystem wide refactorings + misc small drivers in one team
> nowadays). Sean Paul is also doing ChromeOS from Google's pov, so
> could bring that perspective.

So I'm seeing problems keeping it to a small number. We *will* have to cut.

One thing to do is to perhaps require that everybody can talk about at
least one particular process pain-point with a suggested improvement.
Anybody who doesn't have a painpoint (or whose painpoint is something
they don't think can be fixed) could recuse themselves as being
"happy".

Of course, that's not likely to cut down on numbers _that_ much, so
we'll just have to be picky ;)

> For Android I think it'd be great to have Rom Lemarchand invited (he's
> google's overall android kernel engineer).

Good.

Side note: people should think about various infrastructure/testing
people too  So kernel.org, but also things like zero-day etc test
labs.

I do *not* think we needs tons and tons of developers - unless they
have particular maintenance issues.

Particular subsystems should aim to have one person per subsystem that
can speak for that subsystem, I think, unless there are big reasons
why we'd want more and it's particularly contentious.

If we end up with 20 developers / maintainers and 10 people who are
downstream / stable / infrastructure, I think we'd likely have a
reasonable mix.

I think that the top-ten list (that was originally cc'd) was
reasonably obvious, but it was literallty just a "first round".

And it's good to have numbers to show "these are clearly major
top-level maintainers", and people on that short-list should at least
point to an alternate like DaveA already did.

The longer list of 50 was more of a "and here's more people that show
up high in git that should then have other reasons to be there".

                 Linus