diff options
| -rw-r--r-- | Documentation/driver-api/media/index.rst | 1 | ||||
| -rw-r--r-- | Documentation/driver-api/media/maintainer-entry-profile.rst | 21 | ||||
| -rw-r--r-- | Documentation/driver-api/media/media-committers.rst | 203 |
3 files changed, 225 insertions, 0 deletions
diff --git a/Documentation/driver-api/media/index.rst b/Documentation/driver-api/media/index.rst index d5593182a3f9..08fc2cfc07a3 100644 --- a/Documentation/driver-api/media/index.rst +++ b/Documentation/driver-api/media/index.rst @@ -26,6 +26,7 @@ Documentation/userspace-api/media/index.rst :numbered: maintainer-entry-profile + media-committers v4l2-core dtv-core diff --git a/Documentation/driver-api/media/maintainer-entry-profile.rst b/Documentation/driver-api/media/maintainer-entry-profile.rst index c06a84d98d75..c5c00c66d85c 100644 --- a/Documentation/driver-api/media/maintainer-entry-profile.rst +++ b/Documentation/driver-api/media/maintainer-entry-profile.rst @@ -176,6 +176,17 @@ the subsystem's maintainers. The nominated maintainer must have earned a trust relationship with all Media Subsystem Maintainers, as, by being granted Patchwork access, you will take over part of their maintenance tasks. +Media Committers +---------------- + +Experienced and trusted Media Maintainers may be granted commit rights +which allow them to directly push patches to the media development tree instead +of posting a Pull Request for the Media Subsystem Maintainers. This helps +offloading some of the work of the Media Subsystem Maintainers. + +More details about Media Committers' roles and responsibilities can be +found here: :ref:`Media Committers`. + Media development sites ----------------------- @@ -356,9 +367,19 @@ at some moment. See: :ref:`kernel_org_trust_repository`. With the Pull Request workflow, Pull Requests shall use PGP-signed tags. +With the committers' workflow, this is ensured at the time merge request +rights will be granted to the gitlab instance used by the media-committers.git +tree, after receiving the e-mail documented in +:ref:`media-committer-agreement`. + For more details about PGP signing, please read Documentation/process/maintainer-pgp-guide.rst. +Maintaining media maintainer status +----------------------------------- + +See :ref:`Maintain Media Status`. + List of Media Maintainers ------------------------- diff --git a/Documentation/driver-api/media/media-committers.rst b/Documentation/driver-api/media/media-committers.rst new file mode 100644 index 000000000000..a905856f6a61 --- /dev/null +++ b/Documentation/driver-api/media/media-committers.rst @@ -0,0 +1,203 @@ +.. SPDX-License-Identifier: GPL-2.0 + +.. _Media Committers: + +Media Committers +================ + +Who is a Media Committer? +------------------------- + +A Media Committer is a Media Maintainer with patchwork access who has been +granted commit access to push patches from other developers and their own +patches to the +`media-committers <https://gitlab.freedesktop.org/linux-media/media-committers>`_ +tree. + +These commit rights are granted with expectation of responsibility: +committers are people who care about the Linux Kernel as a whole and +about the Linux media subsystem and want to advance its development. It +is also based on a trust relationship among other committers, maintainers +and the Linux Media community. + +As Media Committer you have the following additional responsibilities: + +1. Patches you authored must have a ``Signed-off-by``, ``Reviewed-by`` + or ``Acked-by`` from another Media Maintainer; +2. If a patch introduces a regression, then that must be corrected as soon + as possible. Typically the patch is either reverted, or an additional + patch is committed to fix the regression; +3. If patches are fixing bugs against already released Kernels, including + the reverts mentioned above, the Media Committer shall add the needed + tags. Please see :ref:`Media development workflow` for more details. +4. All Media Committers are responsible for maintaining + `Patchwork <https://patchwork.linuxtv.org/project/linux-media/list/>`_, + updating the state of the patches they review or merge. + + +Becoming a Media Committer +-------------------------- + +Existing Media Committers can nominate a Media Maintainer to be granted +commit rights. The Media Maintainer must have patchwork access, +have been reviewing patches from third parties for some time, and has +demonstrated a good understanding of the maintainer's duties and processes. + +The ultimate responsibility for accepting a nominated committer is up to +the Media Subsystem Maintainers. The nominated committer must have earned a +trust relationship with all Media Subsystem Maintainers, as, by granting you +commit rights, part of their responsibilities are handed over to you. + +Due to that, to become a Media Committer, a consensus between all Media +Subsystem Maintainers is required. + +.. Note:: + + In order to preserve/protect the developers that could have their commit + rights granted, denied or removed as well as the subsystem maintainers who + have the task to accept or deny commit rights, all communication related to + changing commit rights should happen in private as much as possible. + +.. _media-committer-agreement: + +Media Committer's agreement +--------------------------- + +Once a nominated committer is accepted by all Media Subsystem Maintainers, +they will ask if the developer is interested in the nomination and discuss +what area(s) of the media subsystem the committer will be responsible for. +Those areas will typically be the same as the areas that the nominated +committer is already maintaining. + +When the developer accepts being a committer, the new committer shall +explicitly accept the Kernel development policies described under its +Documentation/, and in particular to the rules in this document, by writing +an e-mail to media-committers@linuxtv.org, with a declaration of intent +following the model below:: + + I, John Doe, would like to change my status to: Committer + + As Media Maintainer I accept commit rights for the following areas of + the media subsystem: + + ... + + For the purpose of committing patches to the media-committers tree, + I'll be using my user https://gitlab.freedesktop.org/users/<username>. + +Followed by a formal declaration of agreement with the Kernel development +rules:: + + I agree to follow the Kernel development rules described at: + + https://www.kernel.org/doc/html/latest/driver-api/media/media-committers.rst + + and to the Linux Kernel development process rules. + + I agree to abide by the Code of Conduct as documented in: + https://www.kernel.org/doc/html/latest/process/code-of-conduct.rst + + I am aware that I can, at any point of time, retire. In that case, I will + send an e-mail to notify the Media Subsystem Maintainers for them to revoke + my commit rights. + + I am aware that the Kernel development rules change over time. + By doing a new push to media-committers tree, I understand that I agree + to follow the rules in effect at the time of the commit. + +That e-mail shall be signed via the Kernel Web of trust with a PGP key cross +signed by other Kernel and media developers. As described at +:ref:`media-developers-gpg`, the PGP signature, together with the gitlab user +security are fundamental components that ensure the authenticity of the merge +requests that will happen at the media-committers.git tree. + +In case the kernel development process changes, by merging new commits to the +`media-committers tree <https://gitlab.freedesktop.org/linux-media/media-committers>`_, +the Media Committer implicitly declares their agreement with the latest +version of the documented process including the contents of this file. + +If a Media Committer decides to retire, it is the committer's duty to +notify the Media Subsystem Maintainers about that decision. + +.. note:: + + 1. Changes to the kernel media development process shall be announced in + the media-committers mailing list with a reasonable review period. All + committers are automatically subscribed to that mailing list; + 2. Due to the distributed nature of the Kernel development, it is + possible that kernel development process changes may end being + reviewed/merged at the Linux Docs and/or at the Linux Kernel mailing + lists, especially for the contents under Documentation/process and for + trivial typo fixes. + +Media Core Committers +--------------------- + +A Media Core Committer is a Media Core Maintainer with commit rights. + +As described in Documentation/driver-api/media/maintainer-entry-profile.rst, +a Media Core Maintainer maintains media core frameworks as well, besides +just drivers, and so is allowed to change core files and the media subsystem's +Kernel API. The extent of the core committer's grants will be detailed by the +Media Subsystem Maintainers when they nominate a Media Core Committer. + +Existing Media Committers may become Media Core Committers and vice versa. +Such decisions will be taken in consensus among the Media Subsystem +Maintainers. + +Media committers rules +---------------------- + +Media committers shall do their best efforts to avoid merging patches that +would break any existing drivers. If it breaks, fixup or revert patches +shall be merged as soon as possible, aiming to be merged at the same Kernel +cycle the bug is reported. + +Media committers shall behave accordingly to the rights granted by +the Media Subsystem Maintainers, especially with regards of the scope of changes +they may apply directly at the media-committers tree. That scope can +change over time on a mutual agreement between Media Committers and +Media Subsystem Maintainers. + +The Media Committer workflow is described at :ref:`Media development workflow`. + +.. _Maintain Media Status: + +Maintaining Media Maintainer or Committer status +------------------------------------------------ + +A community of maintainers 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 Maintainer or Committer continues to +disregard good citizenship (or actively disrupts the project), we may need +to revoke that person's status. In such cases, if someone suggests the +revocation with a good reason, then after discussing this among the Media +Maintainers, the final decision is taken by the Media Subsystem Maintainers. + +As the decision to become a Media Maintainer or Committer comes from a +consensus between Media Subsystem Maintainers, a single Media Subsystem +Maintainer not trusting the Media Maintainer or Committer anymore is enough +to revoke their maintenance, Patchwork grants and/or commit rights. + +Having commit rights revoked doesn't prevent Media Maintainers to keep +contributing to the subsystem either via the pull request or via email workflow +as documented at the :ref:`Media development workflow`. + +If a maintainer 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 their maintainer/patchwork and committer rights and update MAINTAINERS +file entries accordingly. If you wish to resume contributing as maintainer +later on, then contact the Media Subsystem Maintainers to ask if your +maintenance, Patchwork grants and commit rights can be restored. + +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 <https://webkit.org/commit-and-review-policy/>`_; +- `Mozilla <https://www.mozilla.org/hacking/committer/>`_. |