Jumping in the middle here with some clarifications. On Wed, 27 Nov 2024 at 12:19, Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx> 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. 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. Cheers, Sima -- Simona Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
