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
