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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20241128190813.GB13852@pendragon.ideasonboard.com>
Date: Thu, 28 Nov 2024 21:08:13 +0200
From: Laurent Pinchart <laurent.pinchart@...asonboard.com>
To: Mauro Carvalho Chehab <mchehab+huawei@...nel.org>
Cc: Simona Vetter <simona.vetter@...ll.ch>, linux-media@...r.kernel.org,
	Jonathan Corbet <corbet@....net>, linux-doc@...r.kernel.org,
	linux-kernel@...r.kernel.org, workflows@...r.kernel.org,
	Hans Verkuil <hverkuil@...ll.nl>
Subject: Re: [PATCH] docs: media: document media multi-committers rules and
 process

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