Re: [PATCH] docs: media: document media multi-committers rules and process

[Mauro Carvalho Chehab <mchehab+huawei@kernel.org>]

Em Wed, 27 Nov 2024 15:48:10 +0100
Simona Vetter <simona.vetter@ffwll.ch> escreveu:

> Jumping in the middle here with some clarifications.
> 
> On Wed, 27 Nov 2024 at 12:19, Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote:
> > On Wed, Nov 27, 2024 at 10:39:48AM +0100, Mauro Carvalho Chehab wrote:  
> > > It is somewhat similar to drm-intel and drm-xe, where reviews are part
> > > of the acceptance criteria to become committers.  
> >
> > Those are corporate trees, so it's easier to set such rules.  
> 
> Imo it's the other way round, because it's corporate you need stricter
> rules and spell them all out clearly - managers just love to apply
> pressure on their engineers too much otherwise "because it's our own
> tree". Totally forgetting that it's still part of the overall upstream,
> and that they don't own upstream.
> 
> So that's why the corporate trees are stricter than drm-misc, but the
> goals are still exactly the same:
> 
> - peer review is required in a tit-for-tat market, but not more.
> 
> - committers push their own stuff, that's all. Senior committers often
>   also push other people's work, like for smaller work they just reviewed
>   or of people they mentor, but it's not required at all.
> 
> - maintainership duties, like sending around pr, making sure patches dont
>   get lost and things like that, is separate from commit rights. In my
>   opinion, if you tie commit rights to maintainership you're doing
>   something else than drm and I'd more call it a group maintainership
>   model, not a commit rights model for landing patches.

Right now, our focus is for driver maintainers to become committers,
so they all have maintainership duties as well.

The requirement we're adding is to ensure that they're doing a
good work as committers/maintainers, reviewing patches from others,
as otherwise nobody will do that.

Now, once we start getting drivers with lots of developers working
on them without maintainership status, we can start including
them, but this is not our reality, as usually, there is usually
only one or, at most a couple of developers per driver.

> Anyway just figured I'll clarify what we do over at drm. I haven't looked
> at all the details of this proposal here and the already lengthy
> discussion, plus it's really not on me to chime in since I'm not involved.

Thanks,
Mauro