On Wed, 27 Nov 2024, Simona Vetter <simona.vetter@xxxxxxxx> wrote: > 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. The required commits and reviews to become a committer may sound somewhat artificial and arbitrary, but it's a sort of compromise. The goal is to have a relatively low bar for entry, while ensuring the committers have just enough experience to judge whether a patch passes merge criteria (more on that below). It's also the same for everyone, and something to strive for. Frankly, I'm not fond of the invite-only model. You need to be careful to not lose transparency. It can be scary to have a lot of committers. You put a lot of trust in them. But at the same time, you do monitor what's going on, and can revert commits - and commit rights, if needed. > 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. I think it's also important to define merge criteria. A set of rules by which a committer can commit. And it's not really about technical checkboxes. For example, in drm it really boils down to two things: at least two people have been involved, and there are no open issues. (And have those people recorded in git trailers with Sob/Rb/Ab, with tooling to ensure that's the case. There are very few commis in drm-misc/drm-intel without either 2xSob, Sob+Rb, or Sob+Ab.) > - 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. Agreed. Personally, I like the committer/maintainer model, because it's a low barrier to entry, with limited responsibilities. Not everyone wants to become even a committer, and the more loaded it becomes, even less so. Yet the committers help maintainers immensely, and you grow a pool of people who can become maintainers. > 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. To be honest, IMO the length is one of the shortcomings of the proposal. Lots of up front process, which will inevitably have to be ironed out as you gain experience. You just won't be able to figure it all out in advance. All that said, I commend all efforts to move towards shared maintainership models, whether it's group maintainership or committer/maintainer model or something in between. Just offering my views here, which you're obviously free to completely ignore to your benefit or detriment. ;) BR, Jani. -- Jani Nikula, Intel
