> > + > > +If a media committer decides to retire, it is the committer's duty to > > +notify the subsystem maintainers about that decision. > > + > > +Maintaining media committer status > > +---------------------------------- > > + > > +A community of committers working together to move the Linux Kernel > > +forward is essential to creating successful projects that are rewarding > > +to work on. If there are problems or disagreements within the community, > > +they can usually be solved through healthy discussion and debate. > > + > > +In the unhappy event that a media committer continues to disregard good > > +citizenship (or actively disrupts the project), we may need to revoke > > That's very, very vague, surprisingly vague even from someone who raised > many concerns about the kernel code of conduct being vague. This text came from Google Chromium committer document: https://chromium.googlesource.com/playground/chromium-org-site/+/refs/heads/main/getting-involved/become-a-committer.md#maintaining-committer-status It is vague, a revoking commit rights is a discretionary act. It is nearly impossible to describe all conditions that could lead a committer to be distrusted. > > +that person's status. In such cases, if someone suggests the revocation with > > +a good reason, other developers may second the motion. The final decision > > +is taken by the subsystem maintainers. As the decision to become a media > > What does "seconding the motion" bring, if the decision lies solely in > maintainers ? The decision is up to maintainers, but other committers/developers may voice about it. > > +committer comes from a consensus between subsystem maintainers, a single > > +subsystem maintainer not trusting the media committer anymore is enough to > > +revoke committer's privileges. > > + > > +If a committer is inactive for more than a couple of Kernel cycles, > > +maintainers will try to reach you via e-mail. If not possible, they may > > +revoke your committer privileges and update MAINTAINERS file entries > > +accordingly. If you wish to resume contributing later on, then contact > > +the subsystem maintainers to ask if your rights can be restored. > > https://drm.pages.freedesktop.org/maintainer-tools/committer/commit-access.html#access-request: > > "Committers are encouraged to request their commit rights get removed > when they no longer contribute to the project. Commit rights may be > automatically revoked after a year of inactivity (no commits or > reviews). I prefer the current version, as it makes clearer that we expect committers to request removal before becoming inactive. > Commit rights will be reinstated when they come back to the > project." This doesn't sound right, as it means that just returning back is an enough condition for having committer grants restored. This should not be automatic: the returned contributors need to opt-in to be committers again, and the maintainers need to be confident that the developers will do their duties before restore committers' grants. > > + > > +A previous committer that had his commit rights revoked can keep contributing > > s/his/their/ > > > +to the subsystem via the normal e-mail workflow as documented at the > > +:ref:`Media development workflow`. > > + > > +References > > +---------- > > + > > +Much of this was inspired by/copied from the committer policies of: > > + > > +- `Chromium <https://chromium.googlesource.com/chromium/src/+/main/docs/contributing.md>`_; > > +- `WebKit <http://www.google.com/url?q=http%3A%2F%2Fwebkit.org%2Fcoding%2Fcommit-review-policy.html&sa=D&sntz=1&usg=AFrqEze4W4Lvbhue4Bywqgbv-N5J66kQgA>`_; > > Google tracks us enough without using google URLs. I'll fix. > > > +- `Mozilla <http://www.google.com/url?q=http%3A%2F%2Fwww.mozilla.org%2Fhacking%2Fcommitter%2F&sa=D&sntz=1&usg=AFrqEzecK7iiXqV30jKibNmmMtzHwtYRTg>`_. > > https://drm.pages.freedesktop.org/maintainer-tools/committer/commit-access.html > would also have been a good source of inspiration. That's the only large > multi-committer workflow today in the kernel, and it has proven its > value. The explicit acceptance criteria in particular are very good. > Quoting the document, it says > > "Commit rights will be granted to anyone who requests them and fulfills > the below criteria:" > > That's how we build an inclusive community, it feels way more welcoming > than saying that maintainers will discuss in private and grant > privileges to underlings if it pleases them (even if the effect is the > same in practice, it's still a maintainer decision). The criteria for drm-misc has a big gap from what we want: "This should not be interpreted as a requirement to review other peoples patches" We do require committers to review other peoples patches. It sounds that the criteria there for xe/i915 partially fixes the issue with drm-misc, as it adds this criteria: "Has reviewed at least 25 patches from other developers to the chosen driver that have already been merged upstream. Again, most of the reviewed patches must be non-trivial." But still it doesn't say that committers shall review other peoples patches(*). (*) Such reviews happen in practice there, but the number of patches from external parties for xe/915 are very small and they usually come from business partners. This is a very different reality than what we have on media. Besides that, in practical terms, we're not ready to accept "anyone". Our current goal is to grant commit rights to the most active developers that have been doing a good work reviewing patches from others. On other words, the focus are on those who has already grants at patchwork to update patches. It doesn't mean that we're limited to them. It is just that we need to implement multi-committers without causing troubles to the subsystem's workflow. Also, we had enough troubles with our past multi-committers model, back in the days we were using Mercurial, because there, we used to grant committer access to "anyone" that were active at the media development. So, it has to be a step-by-step approach. Maybe after a couple of years this will be revisited and we could use a more inclusive text, but first we need to ensure that media-ci, patchwork and the multi-committer's model will work for us on a multi-committers model. Then, we'll likely need a tool similar to `dim` to help with the merge requests and avoid problems that may force maintainers to do rebases. > > > + > > diff --git a/Documentation/process/maintainer-pgp-guide.rst b/Documentation/process/maintainer-pgp-guide.rst > > index f5277993b195..795ef8d89271 100644 > > --- a/Documentation/process/maintainer-pgp-guide.rst > > +++ b/Documentation/process/maintainer-pgp-guide.rst > > @@ -903,6 +903,8 @@ the new default in GnuPG v2). To set it, add (or modify) the > > > > trust-model tofu+pgp > > > > +.. _kernel_org_trust_repository: > > + > > Using the kernel.org web of trust repository > > -------------------------------------------- > > > Thanks, Mauro
