On Thu, Nov 28, 2024 at 07:15:43PM +0100, Mauro Carvalho Chehab wrote: > Em Wed, 27 Nov 2024 15:25:15 +0200 Laurent Pinchart escreveu: > > > > > I think this goes a bit backward, and mixes things up a bit. On the > > > > mixing side, the expectation of timely reviews comes from maintainer > > > > status. Having commit rights is orthogonal to that. > > > > > > > > The goal of direct commit access is to speed up maintenance, to get > > > > patches reviewed and merged quicker. Are we saying here that if someone > > > > has commit rights they will lose them if they take too long to review > > > > code ? That would then slow down maintenance even more, which seems > > > > counterproductive. > > > > > > Someone with commit rights is also a maintainer, since that's how you > > > gain the trust to get those rights. If you do a poor job of reviewing > > > patches relevant for you as maintainer, then you loose that trust. > > > > This is I think the point where our expectations are the least aligned. > > I'm considering "committer" based on what is done in drm-misc. A > > committer is essentially a developer who has demonstrated they can > > follow a documented process to push their own patches. They are given > > push access as a shortcut, which frees time for the subsystem > > maintainers who don't have to pick patches manually from the list (or > > handle pull requests). That's the official side of it. The barrier to > > entry is intentionally kept very low to ensure that committers won't > > decide to use the legacy workflow due to expectations of additional work > > load. Committers are not required or even asked to take any extra work. > > It's still a win-win situation: subsystem maintainers have less work, > > and committers can get their patches upstream more easily. > > > > Then there's the other "secret" goal: through handing out committer > > rights, the maintainers hoped that a subset of the committers would > > become more involved, grow more knowledge about the subsystem, pick up > > third party patches, review or cross-review code, ... And that worked, > > DRM has grown an active community of developers who go beyond their > > personal needs and help with maintenance more broadly. Dave and Sima > > deliberately decided to favour the carrot over the stick, and I think > > the events that followed proved it was the right decision. > > > > This is what I would like to see replicated in the media subsystem. Even > > if a committer only handles the single driver they're interested in and > > push their own patches, it's still a win for everybody involved. By > > making the barrier to entry low, we will make it possible for people who > > would have been scared of volunteering to become part of the community, > > and over time handle more responsibilities. Setting a higher barrier to > > entry will scare those people away. Even myself, if I'm expected to do > > more than what I do today to get commit rights, I won't request them. > > Everybody will lose, I will have to keep sending pull requests, and you > > will have to keep handling them. Both of us will lose time that we could > > otherwise use for reviews or other tasks beneficial to the subsystem. > > > > More importantly than the exact wording, it's the core principle of the > > committers model that we need to agree on. If we don't have the same > > expectations it will clearly not work. > > The reality on media is *very* different from DRM. With DRM, most We're designing a process for the future, it's up to us to design what we want to achieve. > drivers have multiple developers working on it, and the more important > drivers typically have dozens of committers. The vast majority of such There are a few corporate-backed drivers that have bigger teams, but apart from that, it's not as well staffed as you seem to imply. > committers aren't listed at MAINTAINERS file for the drm drivers they > commit patches. > > On media, there's usually just one person that maintains the driver > who will become a committer if they want. > > Right now, my expectation is that *all* committers will also be > a maintainer, e. g. they'll all be listed at MAINTAINERS file, > being responsible by one or more driver. > > Besides that, the multi-committers will replace the current > sub-maintainers workflow. > > We also need to do a slow start to ensure that media-ci, patchwork, > CI integration with patchwork, etc will work properly. > > With that in mind, every committer has duties of reviewing other > developer's patches submitted for the drivers that they're listed as > a maintainer at the MAINTAINERS file entries. I'm sorry but that's not a multi-committer model, it's a co-maintenance model. If that's what you really want we can reopen the discussion and start anew, but I don't think it's a good idea. As I said before, if it increases my work load, I don't want commit rights. I'll keep sending pull requests, you'll have to keep processing them, and patches will be merged slower. It will be a lose-lose situation for everybody, you, me, contributors and users. Starting with a situation where we are understaffed and trying to solve it by putting more work on the few people who currently keep the subsystem alive doesn't sound like a winning strategy. > > > >> +If you are doing such tasks and have become a valued developer, an > > > >> +existing committer can nominate you to the media subsystem maintainers. > > > > > > > > https://drm.pages.freedesktop.org/maintainer-tools/committer/commit-access.html#access-request: > > > > > > > > "Maintainers and committers should encourage contributors to request > > > > commit rights, especially junior contributors tend to underestimate > > > > their skills." > > > > > > In drm is it the contributors that request commit rights? Or is it those > > > who already have commit rights that invite others? Currently the plan for > > > the media subsystem is the second method. Although that might change in the > > > future, of course. > > > > The process is documented in > > https://drm.pages.freedesktop.org/maintainer-tools/committer/commit-access.html#access-request. > > It requires explicit action from the candidate, as they have to create a > > gitlab.fdo account, and request commit access by fiing an issue in > > gitlab. You can see the issue template at > > https://gitlab.freedesktop.org/drm/misc/kernel/-/issues/new?issue[title]=Request%20for%20Commit%20Rights&issuable_template=commit_access, > > which is roughly speaking the equivalent of the mail template in this > > document. In practice, as mentioned in the documentation, people often > > underestimate their skills and lack confidence to ask for committer > > access. That's why the documentation states that maintainers and > > committers should encourage contributors to request access. > > > > I like that model because it requires an explicit action from the > > contributor to show that they have an interest, and it also makes it > > possible for people to request access without having been nominated. It > > doesn't mean that access will be automatically granted, there are still > > acceptance criteria, and it's a maintainer decision at the end of the > > day. > > > > Stating as done in this patch that an existing committer can nominate > > someone implies that contributors have to wait until they get notified > > they can join The Chosen Few. It's not very welcoming, and given how > > busy everybody is, valuable contributors may need to wait for longer > > than they should before someone thinks about nominating them. > > > > I wouldn't expect a change of wording to result in any practical change > > in the process, it is only about being more inclusive and welcoming in > > the document. If we want to create a vibrant community, people should > > feel not just welcome, but also desired and valued. > > The model we're implementing is that the action of becoming a > committer will also have a step where the contributor will show > that they have an interest. > > Yet, right now the goal is to implement the model starting with > active media maintainers. > > Once we get there, and after a couple of kernel releases to test > that everything is working as expected, we may aim to carefully > expand it. -- Regards, Laurent Pinchart
