[Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance

[Daniel Vetter]

On Wed, Sep 12, 2018 at 8:45 PM, Alexandre Belloni
<alexandre.belloni at bootlin.com> wrote:
> On 12/09/2018 11:42:53+0300, Jani Nikula wrote:
>> On Wed, 12 Sep 2018, Alexandre Belloni <alexandre.belloni at bootlin.com> wrote:
>> > Most of the drivers are developed by their maintainer or someone paid
>> > by the vendor (which is basically the same because the maintainer is
>> > actually getting paid to get his colleagues patches upstream).
>> >
>> > I also see that the review numbers hint at biased reviews for the big
>> > drivers as they are not coming from outsiders.
>> >
>> > So what I see in DRM is exactly what you despis in other areas of the
>> > kernel: mostly unreviewed maintainer self commits.
>>
>> I'll only speak for drm/i915 here as one of its maintainers, and I'll
>> steer clear of the preceding debate, but your conclusions don't hold
>> water wrt drm/i915.
>>
>> Sure, most of the contributions, both patches and review, come from paid
>> Intel developers. It's a very busy driver. We pushed just under 8
>> commits per day on the average in the v4.4..v4.18 range. For reference,
>> that's 6.6% of all of drivers/. More than sound/, a bit less than fs/ or
>> net/ top level directories, but in the same ballpark.
>>
>> By our rules, *nobody* gets to push unreviewed patches, and we follow
>> that religiously. The more complicated the patch, the more rigorous the
>> review must be, involving domain experts or generally more sets of eyes.
>>
>
> I hope you do realise that we have to take your word for it because
> there is no way to actually verify that claim. However, I'm all for
> believing you. I'm just claiming that we can't actually know.
>
>> If we had to rely on outside reviews, either our rate of change would
>> grind to a halt,
>
> Exactly, so I guess you can understand that this is basically not
> something that you can ask in any other subsystem that has more than a
> few drivers. There is simply no way to get outside reviews on drivers.

I got bored, counted all the drivers in drm, it's about 100. So not
quite yet where rtc is, but we're getting there. Smallest of these is
just shy of 300 lines of code. Not quite as small as the smallest rtc
driver I agree, but compared to drm/amdgpu a rounding error in
difference really.

So yeah maybe it's all fake review that we're doing, and that's why
it's impossible.
-Daniel


>> or we'd have to loosen our rules. Instead, we trust our
>> maintainers and committers to have the integrity to follow our
>> documented merge criteria. And bypassing the rules would be a fast lane
>> to losing the maintainer/committer status.
>>
>> Anyone contributing to drm/i915 will tell you there are no biased
>> reviews. Some might say we are more gentle towards outside contributors
>> than our own. I'm also pretty confident you won't find examples of
>> unreviewed commits, let alone unreviewed maintainer self commits.
>>
>
> Again, this is a matter of trusting the coworkers reviews and I'm not
> saying that they are not happening, I'm just saying we can't know.
>
> Anyway, you are the ones maintaining your own driver and this is good,
> this is simply what any maintainer should do. I'm pretty convinced that
> you are careful to not break your own driver because that is your best
> interest. And it seems that you are doing a good job as it has been a
> while that I had issues with i915 (I wouldn't have said so two years
> ago).
>
> But again, I'm not sure this is the great success story Daniel claims it
> is. I'm just seeing a maintainer that couldn't keep up with the number
> of patches in his subsystem and created subsubsystems. And this is fine
> because the subsubsystem maintainers have huge incentives to stay around
> (the main one being that they are actually getting paid to do it).
>
> --
> Alexandre Belloni, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch