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

[Laurent Pinchart <laurent.pinchart@ideasonboard.com>]

On Thu, Nov 28, 2024 at 07:28:42PM +0100, Mauro Carvalho Chehab wrote:
> Em Wed, 27 Nov 2024 15:48:10 +0100 Simona Vetter escreveu:
> 
> > Jumping in the middle here with some clarifications.
> > 
> > On Wed, 27 Nov 2024 at 12:19, Laurent Pinchart 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.

Mauro, that may be your focus, but it's not "ours".

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

-- 
Regards,

Laurent Pinchart