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

[Daniel Vetter <daniel.vetter@ffwll.ch>]

On Tue, Apr 18, 2017 at 10:56 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> 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 ;)

Yeah, Sean/Jani probably only make sense if we bikeshed group
maintainer models the entire day.

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

Hm, we're trying to build up a much more ambitious CI here for drm and
intel specifically, but nothing all that interesting yet relevant
beyond drm. What could be interesting (but not for the discussion
session, more for the general track) is getting our userspace CI team
to explain what they do. Except that it runs in userspace the gl
drivers are as much low-level driver nonsense as anything else as far
as drivers go, and the stuff they're pulling off is seriously
impressive. Millions of test runs each day (including pre-merge to
stop any regressions before they even get close to the tree),
contributor numbers and code size on par with a major Linux subsystem,
100+ different machines and all the fun of testing hw ("yep, that
killed all the machines, oops").

A hw testing bof thing for different (driver) subsystems to compare
notes might be good, but I'm not sure that'd be useful for the group
discussions really. Probably more talking to the audience than what
you're aiming for.

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

I do think we overall have some big issues with all the folks who
decide not to contribute to upstream but still ship Linux. Android is
a big one, but socs in general suffer from this. Like you said in
another mail, pointing fingers is no use, least because if we put all
the blame on hw vendors there's nothing we can do on our side to
improve things :-)

Since they don't even show it's hard to find out who'd be a good rep,
so probably not much use getting them in as developers (or I have no
idea how at least). But I do think we have a big gap here (and e.g.
drm for a long time entirely lacked the android perspective in
upstream work, until upstream folks + google worked to fix that).
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch