[PATCHv6 0/3] docs: media: multicommitters model documentation

[PATCHv6 0/3] docs: media: multicommitters model documentation

[Hans Verkuil]

I finally had time to continue Mauro's work on documenting the
multicommitter model.

It is a fairly big overhaul of v5. The most significant change is
that I extended the maintainer profile substantially. A lot of
the committer requirements from the v5 of media-committer.rst were
actually maintainer requirements, so I moved those over to the
maintainer profile.

Patch 1/3 updates maintainer-entry-profile.rst: it introduces the
three Media maintainer levels (Media Maintainer, Media Core Maintainer
and Media Subsystem Maintainer) and what the responsibilities are.

Patch 2/3 adds media-committer.rst: that focusses on the additional
commit rights that can be granted to a Media Maintainer.

Patch 3/3 adds back and updates the list of Media Maintainers that
disappeared in patch 1/3. Please verify this whether the email
addresses are the correct ones, and verify that the areas of responsibility
are correct and that nothing is missing.

It feels much more consistent to me, I'm looking forward to the
review comments.

I have uploaded the documentation with these patches here:

https://hverkuil.home.xs4all.nl/spec/driver-api/maintainer-entry-profile.html
https://hverkuil.home.xs4all.nl/spec/driver-api/media-committer.html

Regards,

	Hans

Hans Verkuil (1):
  docs: media: document Media Maintainers

Mauro Carvalho Chehab (2):
  docs: media: update maintainer-entry-profile for multi-committers
  docs: media: document media multi-committers rules and process

 Documentation/driver-api/media/index.rst      |   1 +
 .../media/maintainer-entry-profile.rst        | 407 +++++++++++++++---
 .../driver-api/media/media-committer.rst      | 196 +++++++++
 3 files changed, 548 insertions(+), 56 deletions(-)
 create mode 100644 Documentation/driver-api/media/media-committer.rst

-- 
2.51.0

[PATCHv6 1/3] docs: media: update maintainer-entry-profile for multi-committers

[Hans Verkuil]

From: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

As the media subsystem will experiment with a multi-committers model,
update the Maintainer's entry profile to the new rules.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Reviewed-by: Ricardo Ribalda <ribalda@chromium.org>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
---
 .../media/maintainer-entry-profile.rst        | 368 +++++++++++++++---
 1 file changed, 308 insertions(+), 60 deletions(-)

diff --git a/Documentation/driver-api/media/maintainer-entry-profile.rst b/Documentation/driver-api/media/maintainer-entry-profile.rst
index 2127e5b15e8f..af499e79b23e 100644
--- a/Documentation/driver-api/media/maintainer-entry-profile.rst
+++ b/Documentation/driver-api/media/maintainer-entry-profile.rst
@@ -4,19 +4,25 @@ Media Subsystem Profile
 Overview
 --------
 
-The media subsystem covers support for a variety of devices: stream
-capture, analog and digital TV streams, cameras, remote controllers, HDMI CEC
-and media pipeline control.
+The Linux Media Community (aka: the LinuxTV Community) is formed of
+developers working on Linux Kernel Media Subsystem, together with users
+who also play an important role in testing the code.
 
-It covers, mainly, the contents of those directories:
+The Media Subsystem has code to support a wide variety of media-related
+devices: stream capture, analog and digital TV streams, cameras,
+video codecs, video processing (resizers, etc.), radio, remote controllers,
+HDMI CEC and media pipeline control.
+
+The Media Subsystem consists of the following directories in the kernel
+tree:
 
   - drivers/media
   - drivers/staging/media
+  - include/media
+  - Documentation/devicetree/bindings/media/\ [1]_
   - Documentation/admin-guide/media
   - Documentation/driver-api/media
   - Documentation/userspace-api/media
-  - Documentation/devicetree/bindings/media/\ [1]_
-  - include/media
 
 .. [1] Device tree bindings are maintained by the
        OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS maintainers
@@ -27,19 +33,264 @@ It covers, mainly, the contents of those directories:
 Both media userspace and Kernel APIs are documented and the documentation
 must be kept in sync with the API changes. It means that all patches that
 add new features to the subsystem must also bring changes to the
-corresponding API files.
+corresponding API documentation.
 
-Due to the size and wide scope of the media subsystem, media's
-maintainership model is to have sub-maintainers that have a broad
-knowledge of a specific aspect of the subsystem. It is the sub-maintainers'
-task to review the patches, providing feedback to users if the patches are
-following the subsystem rules and are properly using the media kernel and
-userspace APIs.
+A small subsystem will typically consist of driver maintainers (as listed
+in the MAINTAINERS file) and one or two subsystem maintainers who merge
+the patches when ready, maintain the subsystem core code and make the pull
+requests to Linus. Due to the size and wide scope of the Media Subsystem
+this does not scale and more maintainance layers are needed.
 
-Patches for the media subsystem must be sent to the media mailing list
-at linux-media@vger.kernel.org as plain text only e-mail. Emails with
-HTML will be automatically rejected by the mail server. It could be wise
-to also copy the sub-maintainer(s).
+Media Maintainers
+-----------------
+
+The media subsystem has three layers of media maintainers:
+
+- Media Maintainer:
+    Responsible for a group of drivers within the Media Subsystem. Typically
+    these are all drivers that have something in common, e.g. codec drivers
+    or drivers from the same vendor. Media Maintainers provide feedback if the
+    patches are not following the subsystem rules, or are not using the
+    media kernel or userspace APIs correctly, or have poor code quality. They
+    also keep patchwork up to date, decide when patches are ready for merging,
+    and create Pull Requests for the Media Subsystem Maintainers to merge.
+
+    A Media Maintainer is not just someone who is capable of creating code, but
+    someone who has demonstrated their ability to collaborate with the team, get
+    the most knowledgeable people to review code, contribute high-quality code,
+    and follow through to fix issues (in code or tests).
+
+- Media Core Maintainer:
+    Media Maintainers who are also responsible for one or more media core
+    frameworks.
+
+    Core framework changes are done via consensus between the relevant Media
+    Core Maintainers. Media Maintainers may include core framework changes in
+    their Pull Requests if they are signed off by the relevant Media Core
+    Maintainers.
+
+- Media Subsystem Maintainers:
+    Responsible for the subsystem as a whole, with access to the
+    entire subsystem. Responsible for merging Pull Requests from other
+    Media Maintainers.
+
+    Userspace API/ABI changes are done via consensus between Media Subsystem
+    Maintainers\ [2]_. Media (Core) Maintainers may include API/ABI changes in
+    their Pull Requests if they are signed off by the all Media Subsystem
+    Maintainers.
+
+All Media Maintainers shall explicitly agree with the Kernel development process
+as described at Documentation/process/index.rst and to the Kernel
+development rules inside the Kernel documentation, including its code of
+conduct.
+
+All Media Maintainers shall ensure that patchwork will reflect the current
+status, e.g. patches shall be delegated to the Media Maintainer who is
+handling them and the patch status shall be updated according to these rules:
+
+- ``Under Review``: Used if the patch requires a second opinion
+  or when it is part of a pull request;
+- ``Accepted``: Once a patch is merged in the multi-committer tree.
+- ``Superseded``: There is a newer version of the patch posted to the
+  mailing list.
+- ``Duplicated``: There was another patch doing the same thing from someone
+  else that was accepted.
+- ``Not Applicable``: Use for patch series that are not merged at media.git
+  tree (e.g. drm, dmabuf, upstream merge, etc.) but were cross-posted to the
+  linux-media mailing list.
+
+If the Media Maintainer decides not to accept a patch, then reply by email to
+the patch authors, explaining why it is not accepted, and patchwork shall be
+updated accordingly with either:
+
+- ``Changes Requested``: if a new revision was requested;
+- ``Rejected``: if the proposed change is not acceptable at all.
+
+.. Note::
+
+   Patchwork supports a couple of clients to help semi-automating
+   status updates via its REST interface:
+
+   https://patchwork.readthedocs.io/en/latest/usage/clients/
+
+Media Maintainers are reachable via the #linux-media IRC channel at OFTC.
+
+.. [2] Everything that would break backward compatibility with existing
+       non-kernel code are API/ABI changes. This includes ioctl and sysfs
+       interfaces, v4l2 controls, and their behaviors.
+
+Becoming a Media Maintainer
+---------------------------
+
+The most important aspect of volunteering to be a Media Maintainer is that you
+have demonstrated the ability to give good code reviews. So we are looking for
+whether or not we think you will be good at doing that.
+
+As such, potential maintainers must earn enough credibility and trust from the
+Linux Media Community. To do that, developers shall be familiar with the open
+source model and have been active in the Linux Kernel community for some time,
+and, in particular, in the media subsystem.
+
+In addition to actually making the code changes, you are basically
+demonstrating your:
+
+- commitment to the project;
+- ability to collaborate with the team and communicate well;
+- understand of how upstream and the Linux Media Community work
+  (policies, processes for testing, code review, ...)
+- reasonable knowledge about:
+
+  - the Kernel development process:
+    Documentation/process/index.rst
+
+  - the Media development profile:
+    Documentation/driver-api/media/maintainer-entry-profile.rst
+
+- understanding of the projects' code base and coding style;
+- ability to provide feedback to the patch authors;
+- ability to judge when a patch might be ready for review and to submit;
+- ability to write good code (last but certainly not least).
+
+Developers that desire to become maintainers are encouraged to participate
+at the yearly Linux Media Summit, typically co-located with a Linux related
+conference. These summits will be announced at the linux-media mailing list.
+
+If you are doing such tasks and have become a valued developer, an
+existing Media Maintainer can nominate you to the Media Subsystem Maintainers.
+
+The ultimate responsibility for accepting a nominated maintainer is up to
+the subsystem's maintainers. The nominated maintainer must have earned a trust
+relationship with all Media Subsystem Maintainers, as, by becoming Media
+Maintainer, you will take over part of their maintenance tasks.
+
+Media Committers
+----------------
+
+Experienced and trusted Media (Core) 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.
+
+Media development tree
+----------------------
+
+The main development tree used by the media subsystem is hosted at
+gitlab.freedesktop.org. LinuxTV.org hosts news about the subsystem, wiki pages
+and a patchwork instance where we track patches though their lifetime.
+
+The main tree used by media developers is at:
+
+https://gitlab.freedesktop.org/linux-media/media-committers.git
+
+Please note that this tree can be rebased, although only as a last resort.
+
+.. _Media development workflow:
+
+Media development workflow
+++++++++++++++++++++++++++
+
+All changes for the media subsystem shall be sent first as e-mails to the
+media mailing list, following the process documented at
+Documentation/process/index.rst.
+
+It means that patches shall be submitted as plain text only via e-mail to
+linux-media@vger.kernel.org (aka: LMML). While subscription is not mandatory,
+you can find details about how to subscribe to it and to see its archives at:
+
+  https://subspace.kernel.org/vger.kernel.org.html
+
+Emails with HTML will be automatically rejected by the mail server.
+
+It could be wise to also copy the Media Maintainer(s). You should use
+``scripts/get_maintainers.pl`` to identify whom else needs to be copied.
+Please always copy driver's authors and maintainers.
+
+To minimize the chance of merge conflicts for your patch series, and make
+easier to backport patches to stable Kernels, we recommend that you use the
+following baseline for your patch series:
+
+1. Features for the next mainline release:
+
+   - baseline shall be the media-committers.git ``next`` branch;
+
+2. Bug fixes for the next mainline release:
+
+   - baseline shall be the media-committers.git ``next`` branch. If the
+     changes depend on a fix from the media-committers.git
+     ``fixes`` branch, then you can use that as baseline.
+
+3. Bug fixes for the current mainline release (-rcX):
+
+   - baseline shall be the latest mainline -rcX release or the
+     media-committers.git ``fixes`` branch if changes depend on a mainline
+     fix that is not yet merged;
+
+.. Note::
+
+   See https://www.kernel.org/category/releases.html for an overview
+   about Kernel release types.
+
+Patches with fixes shall have:
+
+- a ``Fixes:`` tag pointing to the first commit that introduced the bug;
+- when applicable, a ``Cc: stable@vger.kernel.org``.
+
+Patches that were fixing bugs publicly reported by someone at the
+linux-media@vger.kernel.org mailing list shall have:
+
+- a ``Reported-by:`` tag immediately followed by a ``Closes:`` tag.
+
+Patches that change API shall update documentation accordingly at the
+same patch series.
+
+See Documentation/process/index.rst for more details about e-mail submission.
+
+Once a patch is submitted, it may follow either one of the following
+workflows:
+
+a. Media Maintainers' workflow: Media Maintainers post the PRs, which
+   are handled by the Media Subsystem Maintainers::
+
+     +-------+   +------------+   +------+   +-------+   +----------------------------+
+     |e-mail |-->|picked up by|-->|code  |-->|pull   |-->|Subsystem Maintainers merge |
+     |to LMML|   |patchwork   |   |review|   |request|   |in media-committers.git     |
+     +-------+   +------------+   +------+   +-------+   +----------------------------+
+
+   For this workflow, pull requests are generated by Media Maintainers.
+   If you are not a Media Maintainer, then please don't submit pull requests,
+   as they will not be processed.
+
+b. Media Committers' workflow: patches are handled by Media Maintainers with
+   commit rights::
+
+     +-------+   +------------+   +------+   +--------------------------+
+     |e-mail |-->|picked up by|-->|code  |-->|Media Committers merge in |
+     |to LMML|   |patchwork   |   |review|   |media-committers.git      |
+     +-------+   +------------+   +------+   +--------------------------+
+
+When patches are picked up by patchwork and when merged at media-committers,
+Media CI bots will check for errors and may provide e-mail feedback about
+patch problems. When this happens, the patch submitter must fix them or
+explain why the errors are false positives.
+
+Patches will only be moved to the next stage in these two workflows if they
+pass on Media CI or if there are false-positives in the Media CI reports.
+
+For both workflows, all patches shall be properly reviewed at
+linux-media@vger.kernel.org (LMML) before being merged in media-committers.git.
+Media patches will be reviewed in a timely manner by the maintainers and
+reviewers as listed in the MAINTAINERS file.
+
+Media Maintainers shall request reviews from other Media Maintainers and
+developers where applicable, i.e. because those developers have more
+knowledge about some areas that are changed by a patch.
+
+There shall be no open issues or unresolved or conflicting feedback
+from anyone. Clear them up first. Defer to the Media Subsystem
+Maintainers if needed.
+
+Failures during e-mail submission
++++++++++++++++++++++++++++++++++
 
 Media's workflow is heavily based on Patchwork, meaning that, once a patch
 is submitted, the e-mail will first be accepted by the mailing list
@@ -47,51 +298,49 @@ server, and, after a while, it should appear at:
 
    - https://patchwork.linuxtv.org/project/linux-media/list/
 
-If it doesn't automatically appear there after a few minutes, then
+If it doesn't automatically appear there after some time [3]_, then
 probably something went wrong on your submission. Please check if the
-email is in plain text\ [2]_ only and if your emailer is not mangling
+email is in plain text\ [4]_ only and if your emailer is not mangling
 whitespaces before complaining or submitting them again.
 
-You can check if the mailing list server accepted your patch, by looking at:
+To troubleshoot problems, you should first check if the mailing list
+server has accepted your patch, by looking at:
 
    - https://lore.kernel.org/linux-media/
 
-.. [2] If your email contains HTML, the mailing list server will simply
+If the patch is there and not at patchwork, it is likely that your e-mailer
+mangled the patch. Patchwork internally has logic that checks if the
+received e-mail contains a valid patch. Any whitespace and new line
+breakages mangling the patch won't be recognized by patchwork, thus such
+patch will be rejected.
+
+.. [3] It usually takes a few minutes for the patch to arrive, but
+       the e-mail server may be busy, so it may take up a longer time
+       for a patch to be picked by patchwork.
+
+.. [4] If your email contains HTML, the mailing list server will simply
        drop it, without any further notice.
 
+.. _media-developers-gpg:
 
-Media maintainers
-+++++++++++++++++
+Authentication for pull and merge requests
+++++++++++++++++++++++++++++++++++++++++++
 
-At the media subsystem, we have a group of senior developers that
-are responsible for doing the code reviews at the drivers (also known as
-sub-maintainers), and another senior developer responsible for the
-subsystem as a whole. For core changes, whenever possible, multiple
-media maintainers do the review.
+The authenticity of developers submitting pull requests and merge requests
+shall be validated by using PGP signing at some moment.
+See: :ref:`kernel_org_trust_repository`.
 
-The media maintainers that work on specific areas of the subsystem are:
+With the pull request workflow, pull requests shall use PGP-signed tags.
 
-- Remote Controllers (infrared):
-    Sean Young <sean@mess.org>
+For more details about PGP sign, please read
+Documentation/process/maintainer-pgp-guide.rst.
 
-- HDMI CEC:
-    Hans Verkuil <hverkuil@kernel.org>
+Subsystem Media Maintainers
+---------------------------
 
-- Media controller drivers:
-    Laurent Pinchart <laurent.pinchart@ideasonboard.com>
-
-- ISP, v4l2-async, v4l2-fwnode, v4l2-flash-led-class and Sensor drivers:
-    Sakari Ailus <sakari.ailus@linux.intel.com>
-
-- V4L2 drivers and core V4L2 frameworks:
-    Hans Verkuil <hverkuil@kernel.org>
-
-The subsystem maintainer is:
-  Mauro Carvalho Chehab <mchehab@kernel.org>
-
-Media maintainers may delegate a patch to other media maintainers as needed.
-On such case, checkpatch's ``delegate`` field indicates who's currently
-responsible for reviewing a patch.
+The subsystem maintainers are:
+  - Mauro Carvalho Chehab <mchehab@kernel.org>
+  - Hans Verkuil <hverkuil@kernel.org>
 
 Submit Checklist Addendum
 -------------------------
@@ -106,18 +355,15 @@ that should be used in order to check if the drivers are properly
 implementing the media APIs:
 
 ====================	=======================================================
-Type			Tool
+Type			Utility
 ====================	=======================================================
-V4L2 drivers\ [3]_	``v4l2-compliance``
+V4L2 drivers\ [5]_	``v4l2-compliance``
 V4L2 virtual drivers	``contrib/test/test-media``
 CEC drivers		``cec-compliance``
 ====================	=======================================================
 
-.. [3] The ``v4l2-compliance`` also covers the media controller usage inside
-       V4L2 drivers.
-
-Other compliance tools are under development to check other parts of the
-subsystem.
+.. [5] The ``v4l2-compliance`` utility also covers the media controller usage
+       inside V4L2 drivers.
 
 Those tests need to pass before the patches go upstream.
 
@@ -134,6 +380,8 @@ Where the check script is::
 Be sure to not introduce new warnings on your patches without a
 very good reason.
 
+Please see `Media development workflow`_ for e-mail submission rules.
+
 Style Cleanup Patches
 +++++++++++++++++++++
 
@@ -183,23 +431,23 @@ In particular, we accept lines with more than 80 columns:
 Key Cycle Dates
 ---------------
 
-New submissions can be sent at any time, but if they intend to hit the
+New submissions can be sent at any time, but if they are intended to hit the
 next merge window they should be sent before -rc5, and ideally stabilized
 in the linux-media branch by -rc6.
 
 Review Cadence
 --------------
 
-Provided that your patch is at https://patchwork.linuxtv.org, it should
+Provided that your patch has landed in https://patchwork.linuxtv.org, it should
 be sooner or later handled, so you don't need to re-submit a patch.
 
-Except for bug fixes, we don't usually add new patches to the development
-tree between -rc6 and the next -rc1.
+Except for important bug fixes, we don't usually add new patches to the
+development tree between -rc6 and the next -rc1.
 
 Please notice that the media subsystem is a high traffic one, so it
 could take a while for us to be able to review your patches. Feel free
 to ping if you don't get a feedback in a couple of weeks or to ask
-other developers to publicly add Reviewed-by and, more importantly,
+other developers to publicly add ``Reviewed-by:`` and, more importantly,
 ``Tested-by:`` tags.
 
 Please note that we expect a detailed description for ``Tested-by:``,
-- 
2.51.0

Re: [PATCHv6 1/3] docs: media: update maintainer-entry-profile for multi-committers

[Sean Young]

On Mon, Oct 27, 2025 at 02:28:31PM +0100, Hans Verkuil wrote:
> From: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
> 
> As the media subsystem will experiment with a multi-committers model,
> update the Maintainer's entry profile to the new rules.
> 
> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
> Reviewed-by: Ricardo Ribalda <ribalda@chromium.org>
> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>

I've read it and I only have some tiny nits, looks great.

Reviewed-by: Sean Young <sean@mess.org>

> ---
>  .../media/maintainer-entry-profile.rst        | 368 +++++++++++++++---
>  1 file changed, 308 insertions(+), 60 deletions(-)
> 
> diff --git a/Documentation/driver-api/media/maintainer-entry-profile.rst b/Documentation/driver-api/media/maintainer-entry-profile.rst
> index 2127e5b15e8f..af499e79b23e 100644
> --- a/Documentation/driver-api/media/maintainer-entry-profile.rst
> +++ b/Documentation/driver-api/media/maintainer-entry-profile.rst
> @@ -4,19 +4,25 @@ Media Subsystem Profile
>  Overview
>  --------
>  
> -The media subsystem covers support for a variety of devices: stream
> -capture, analog and digital TV streams, cameras, remote controllers, HDMI CEC
> -and media pipeline control.
> +The Linux Media Community (aka: the LinuxTV Community) is formed of
> +developers working on Linux Kernel Media Subsystem, together with users
> +who also play an important role in testing the code.
>  
> -It covers, mainly, the contents of those directories:
> +The Media Subsystem has code to support a wide variety of media-related
> +devices: stream capture, analog and digital TV streams, cameras,
> +video codecs, video processing (resizers, etc.), radio, remote controllers,
> +HDMI CEC and media pipeline control.
> +
> +The Media Subsystem consists of the following directories in the kernel
> +tree:
>  
>    - drivers/media
>    - drivers/staging/media
> +  - include/media
> +  - Documentation/devicetree/bindings/media/\ [1]_
>    - Documentation/admin-guide/media
>    - Documentation/driver-api/media
>    - Documentation/userspace-api/media
> -  - Documentation/devicetree/bindings/media/\ [1]_
> -  - include/media
>  
>  .. [1] Device tree bindings are maintained by the
>         OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS maintainers
> @@ -27,19 +33,264 @@ It covers, mainly, the contents of those directories:
>  Both media userspace and Kernel APIs are documented and the documentation
>  must be kept in sync with the API changes. It means that all patches that
>  add new features to the subsystem must also bring changes to the
> -corresponding API files.
> +corresponding API documentation.
>  
> -Due to the size and wide scope of the media subsystem, media's
> -maintainership model is to have sub-maintainers that have a broad
> -knowledge of a specific aspect of the subsystem. It is the sub-maintainers'
> -task to review the patches, providing feedback to users if the patches are
> -following the subsystem rules and are properly using the media kernel and
> -userspace APIs.
> +A small subsystem will typically consist of driver maintainers (as listed
> +in the MAINTAINERS file) and one or two subsystem maintainers who merge
> +the patches when ready, maintain the subsystem core code and make the pull
> +requests to Linus. Due to the size and wide scope of the Media Subsystem
> +this does not scale and more maintainance layers are needed.
>  
> -Patches for the media subsystem must be sent to the media mailing list
> -at linux-media@vger.kernel.org as plain text only e-mail. Emails with
> -HTML will be automatically rejected by the mail server. It could be wise
> -to also copy the sub-maintainer(s).
> +Media Maintainers
> +-----------------
> +
> +The media subsystem has three layers of media maintainers:
> +
> +- Media Maintainer:
> +    Responsible for a group of drivers within the Media Subsystem. Typically
> +    these are all drivers that have something in common, e.g. codec drivers
> +    or drivers from the same vendor. Media Maintainers provide feedback if the
> +    patches are not following the subsystem rules, or are not using the
> +    media kernel or userspace APIs correctly, or have poor code quality. They
> +    also keep patchwork up to date, decide when patches are ready for merging,
> +    and create Pull Requests for the Media Subsystem Maintainers to merge.
> +
> +    A Media Maintainer is not just someone who is capable of creating code, but
> +    someone who has demonstrated their ability to collaborate with the team, get
> +    the most knowledgeable people to review code, contribute high-quality code,
> +    and follow through to fix issues (in code or tests).
> +
> +- Media Core Maintainer:
> +    Media Maintainers who are also responsible for one or more media core
> +    frameworks.
> +
> +    Core framework changes are done via consensus between the relevant Media
> +    Core Maintainers. Media Maintainers may include core framework changes in
> +    their Pull Requests if they are signed off by the relevant Media Core
> +    Maintainers.
> +
> +- Media Subsystem Maintainers:
> +    Responsible for the subsystem as a whole, with access to the
> +    entire subsystem. Responsible for merging Pull Requests from other
> +    Media Maintainers.
> +
> +    Userspace API/ABI changes are done via consensus between Media Subsystem
> +    Maintainers\ [2]_. Media (Core) Maintainers may include API/ABI changes in
> +    their Pull Requests if they are signed off by the all Media Subsystem
> +    Maintainers.
> +
> +All Media Maintainers shall explicitly agree with the Kernel development process
> +as described at Documentation/process/index.rst and to the Kernel
> +development rules inside the Kernel documentation, including its code of
> +conduct.
> +
> +All Media Maintainers shall ensure that patchwork will reflect the current

How about making patchwork a link to our patchwork. Note that patchwork is
mentioned a few times in this file, all of them could be a link.

> +status, e.g. patches shall be delegated to the Media Maintainer who is
> +handling them and the patch status shall be updated according to these rules:
> +
> +- ``Under Review``: Used if the patch requires a second opinion
> +  or when it is part of a pull request;
> +- ``Accepted``: Once a patch is merged in the multi-committer tree.
> +- ``Superseded``: There is a newer version of the patch posted to the
> +  mailing list.
> +- ``Duplicated``: There was another patch doing the same thing from someone
> +  else that was accepted.
> +- ``Not Applicable``: Use for patch series that are not merged at media.git
> +  tree (e.g. drm, dmabuf, upstream merge, etc.) but were cross-posted to the
> +  linux-media mailing list.
> +
> +If the Media Maintainer decides not to accept a patch, then reply by email to
> +the patch authors, explaining why it is not accepted, and patchwork shall be
> +updated accordingly with either:
> +
> +- ``Changes Requested``: if a new revision was requested;
> +- ``Rejected``: if the proposed change is not acceptable at all.
> +
> +.. Note::
> +
> +   Patchwork supports a couple of clients to help semi-automating
> +   status updates via its REST interface:
> +
> +   https://patchwork.readthedocs.io/en/latest/usage/clients/
> +
> +Media Maintainers are reachable via the #linux-media IRC channel at OFTC.
> +
> +.. [2] Everything that would break backward compatibility with existing
> +       non-kernel code are API/ABI changes. This includes ioctl and sysfs
> +       interfaces, v4l2 controls, and their behaviors.
> +
> +Becoming a Media Maintainer
> +---------------------------
> +
> +The most important aspect of volunteering to be a Media Maintainer is that you
> +have demonstrated the ability to give good code reviews. So we are looking for
> +whether or not we think you will be good at doing that.
> +
> +As such, potential maintainers must earn enough credibility and trust from the
> +Linux Media Community. To do that, developers shall be familiar with the open
> +source model and have been active in the Linux Kernel community for some time,
> +and, in particular, in the media subsystem.
> +
> +In addition to actually making the code changes, you are basically
> +demonstrating your:
> +
> +- commitment to the project;
> +- ability to collaborate with the team and communicate well;
> +- understand of how upstream and the Linux Media Community work
> +  (policies, processes for testing, code review, ...)
> +- reasonable knowledge about:
> +
> +  - the Kernel development process:
> +    Documentation/process/index.rst
> +
> +  - the Media development profile:
> +    Documentation/driver-api/media/maintainer-entry-profile.rst
> +
> +- understanding of the projects' code base and coding style;
> +- ability to provide feedback to the patch authors;
> +- ability to judge when a patch might be ready for review and to submit;
> +- ability to write good code (last but certainly not least).
> +
> +Developers that desire to become maintainers are encouraged to participate
> +at the yearly Linux Media Summit, typically co-located with a Linux related
> +conference. These summits will be announced at the linux-media mailing list.

These summits are announced on the linux-media mailing list.


> +
> +If you are doing such tasks and have become a valued developer, an
> +existing Media Maintainer can nominate you to the Media Subsystem Maintainers.
> +
> +The ultimate responsibility for accepting a nominated maintainer is up to
> +the subsystem's maintainers. The nominated maintainer must have earned a trust
> +relationship with all Media Subsystem Maintainers, as, by becoming Media
> +Maintainer, you will take over part of their maintenance tasks.
> +
> +Media Committers
> +----------------
> +
> +Experienced and trusted Media (Core) 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.
> +
> +Media development tree
> +----------------------
> +
> +The main development tree used by the media subsystem is hosted at
> +gitlab.freedesktop.org. LinuxTV.org hosts news about the subsystem, wiki pages
> +and a patchwork instance where we track patches though their lifetime.

Should all be links (LinuxTV.org, patchwork, wiki, gitlab.freedesktop.org).

> +
> +The main tree used by media developers is at:
> +
> +https://gitlab.freedesktop.org/linux-media/media-committers.git
> +
> +Please note that this tree can be rebased, although only as a last resort.
> +
> +.. _Media development workflow:
> +
> +Media development workflow
> +++++++++++++++++++++++++++
> +
> +All changes for the media subsystem shall be sent first as e-mails to the
> +media mailing list, following the process documented at
> +Documentation/process/index.rst.
> +
> +It means that patches shall be submitted as plain text only via e-mail to
> +linux-media@vger.kernel.org (aka: LMML). While subscription is not mandatory,
> +you can find details about how to subscribe to it and to see its archives at:
> +
> +  https://subspace.kernel.org/vger.kernel.org.html
> +
> +Emails with HTML will be automatically rejected by the mail server.
> +
> +It could be wise to also copy the Media Maintainer(s). You should use
> +``scripts/get_maintainers.pl`` to identify whom else needs to be copied.
> +Please always copy driver's authors and maintainers.

git config for using scripts/get_maintainers.pl is useful

> +
> +To minimize the chance of merge conflicts for your patch series, and make
> +easier to backport patches to stable Kernels, we recommend that you use the
> +following baseline for your patch series:
> +
> +1. Features for the next mainline release:
> +
> +   - baseline shall be the media-committers.git ``next`` branch;
> +
> +2. Bug fixes for the next mainline release:
> +
> +   - baseline shall be the media-committers.git ``next`` branch. If the
> +     changes depend on a fix from the media-committers.git
> +     ``fixes`` branch, then you can use that as baseline.
> +
> +3. Bug fixes for the current mainline release (-rcX):
> +
> +   - baseline shall be the latest mainline -rcX release or the
> +     media-committers.git ``fixes`` branch if changes depend on a mainline
> +     fix that is not yet merged;
> +
> +.. Note::
> +
> +   See https://www.kernel.org/category/releases.html for an overview
> +   about Kernel release types.
> +
> +Patches with fixes shall have:
> +
> +- a ``Fixes:`` tag pointing to the first commit that introduced the bug;
> +- when applicable, a ``Cc: stable@vger.kernel.org``.
> +
> +Patches that were fixing bugs publicly reported by someone at the
> +linux-media@vger.kernel.org mailing list shall have:
> +
> +- a ``Reported-by:`` tag immediately followed by a ``Closes:`` tag.
> +
> +Patches that change API shall update documentation accordingly at the
> +same patch series.
> +
> +See Documentation/process/index.rst for more details about e-mail submission.
> +
> +Once a patch is submitted, it may follow either one of the following
> +workflows:
> +
> +a. Media Maintainers' workflow: Media Maintainers post the PRs, which
> +   are handled by the Media Subsystem Maintainers::
> +
> +     +-------+   +------------+   +------+   +-------+   +----------------------------+
> +     |e-mail |-->|picked up by|-->|code  |-->|pull   |-->|Subsystem Maintainers merge |
> +     |to LMML|   |patchwork   |   |review|   |request|   |in media-committers.git     |
> +     +-------+   +------------+   +------+   +-------+   +----------------------------+
> +
> +   For this workflow, pull requests are generated by Media Maintainers.
> +   If you are not a Media Maintainer, then please don't submit pull requests,
> +   as they will not be processed.
> +
> +b. Media Committers' workflow: patches are handled by Media Maintainers with
> +   commit rights::
> +
> +     +-------+   +------------+   +------+   +--------------------------+
> +     |e-mail |-->|picked up by|-->|code  |-->|Media Committers merge in |
> +     |to LMML|   |patchwork   |   |review|   |media-committers.git      |
> +     +-------+   +------------+   +------+   +--------------------------+
> +
> +When patches are picked up by patchwork and when merged at media-committers,
> +Media CI bots will check for errors and may provide e-mail feedback about
> +patch problems. When this happens, the patch submitter must fix them or
> +explain why the errors are false positives.
> +
> +Patches will only be moved to the next stage in these two workflows if they
> +pass on Media CI or if there are false-positives in the Media CI reports.
> +
> +For both workflows, all patches shall be properly reviewed at
> +linux-media@vger.kernel.org (LMML) before being merged in media-committers.git.
> +Media patches will be reviewed in a timely manner by the maintainers and
> +reviewers as listed in the MAINTAINERS file.
> +
> +Media Maintainers shall request reviews from other Media Maintainers and
> +developers where applicable, i.e. because those developers have more
> +knowledge about some areas that are changed by a patch.
> +
> +There shall be no open issues or unresolved or conflicting feedback
> +from anyone. Clear them up first. Defer to the Media Subsystem
> +Maintainers if needed.
> +
> +Failures during e-mail submission
> ++++++++++++++++++++++++++++++++++
>  
>  Media's workflow is heavily based on Patchwork, meaning that, once a patch
>  is submitted, the e-mail will first be accepted by the mailing list
> @@ -47,51 +298,49 @@ server, and, after a while, it should appear at:
>  
>     - https://patchwork.linuxtv.org/project/linux-media/list/
>  
> -If it doesn't automatically appear there after a few minutes, then
> +If it doesn't automatically appear there after some time [3]_, then
>  probably something went wrong on your submission. Please check if the
> -email is in plain text\ [2]_ only and if your emailer is not mangling
> +email is in plain text\ [4]_ only and if your emailer is not mangling
>  whitespaces before complaining or submitting them again.
>  
> -You can check if the mailing list server accepted your patch, by looking at:
> +To troubleshoot problems, you should first check if the mailing list
> +server has accepted your patch, by looking at:
>  
>     - https://lore.kernel.org/linux-media/
>  
> -.. [2] If your email contains HTML, the mailing list server will simply
> +If the patch is there and not at patchwork, it is likely that your e-mailer
> +mangled the patch. Patchwork internally has logic that checks if the
> +received e-mail contains a valid patch. Any whitespace and new line
> +breakages mangling the patch won't be recognized by patchwork, thus such
> +patch will be rejected.
> +
> +.. [3] It usually takes a few minutes for the patch to arrive, but
> +       the e-mail server may be busy, so it may take up a longer time
> +       for a patch to be picked by patchwork.
> +
> +.. [4] If your email contains HTML, the mailing list server will simply
>         drop it, without any further notice.
>  
> +.. _media-developers-gpg:
>  
> -Media maintainers
> -+++++++++++++++++
> +Authentication for pull and merge requests
> +++++++++++++++++++++++++++++++++++++++++++
>  
> -At the media subsystem, we have a group of senior developers that
> -are responsible for doing the code reviews at the drivers (also known as
> -sub-maintainers), and another senior developer responsible for the
> -subsystem as a whole. For core changes, whenever possible, multiple
> -media maintainers do the review.
> +The authenticity of developers submitting pull requests and merge requests
> +shall be validated by using PGP signing at some moment.
> +See: :ref:`kernel_org_trust_repository`.
>  
> -The media maintainers that work on specific areas of the subsystem are:
> +With the pull request workflow, pull requests shall use PGP-signed tags.
>  
> -- Remote Controllers (infrared):
> -    Sean Young <sean@mess.org>
> +For more details about PGP sign, please read
> +Documentation/process/maintainer-pgp-guide.rst.
>  
> -- HDMI CEC:
> -    Hans Verkuil <hverkuil@kernel.org>
> +Subsystem Media Maintainers
> +---------------------------
>  
> -- Media controller drivers:
> -    Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> -
> -- ISP, v4l2-async, v4l2-fwnode, v4l2-flash-led-class and Sensor drivers:
> -    Sakari Ailus <sakari.ailus@linux.intel.com>
> -
> -- V4L2 drivers and core V4L2 frameworks:
> -    Hans Verkuil <hverkuil@kernel.org>
> -
> -The subsystem maintainer is:
> -  Mauro Carvalho Chehab <mchehab@kernel.org>
> -
> -Media maintainers may delegate a patch to other media maintainers as needed.
> -On such case, checkpatch's ``delegate`` field indicates who's currently
> -responsible for reviewing a patch.
> +The subsystem maintainers are:
> +  - Mauro Carvalho Chehab <mchehab@kernel.org>
> +  - Hans Verkuil <hverkuil@kernel.org>
>  
>  Submit Checklist Addendum
>  -------------------------
> @@ -106,18 +355,15 @@ that should be used in order to check if the drivers are properly
>  implementing the media APIs:
>  
>  ====================	=======================================================
> -Type			Tool
> +Type			Utility
>  ====================	=======================================================
> -V4L2 drivers\ [3]_	``v4l2-compliance``
> +V4L2 drivers\ [5]_	``v4l2-compliance``
>  V4L2 virtual drivers	``contrib/test/test-media``
>  CEC drivers		``cec-compliance``
>  ====================	=======================================================
>  
> -.. [3] The ``v4l2-compliance`` also covers the media controller usage inside
> -       V4L2 drivers.
> -
> -Other compliance tools are under development to check other parts of the
> -subsystem.
> +.. [5] The ``v4l2-compliance`` utility also covers the media controller usage
> +       inside V4L2 drivers.
>  
>  Those tests need to pass before the patches go upstream.
>  
> @@ -134,6 +380,8 @@ Where the check script is::
>  Be sure to not introduce new warnings on your patches without a
>  very good reason.
>  
> +Please see `Media development workflow`_ for e-mail submission rules.
> +
>  Style Cleanup Patches
>  +++++++++++++++++++++
>  
> @@ -183,23 +431,23 @@ In particular, we accept lines with more than 80 columns:
>  Key Cycle Dates
>  ---------------
>  
> -New submissions can be sent at any time, but if they intend to hit the
> +New submissions can be sent at any time, but if they are intended to hit the
>  next merge window they should be sent before -rc5, and ideally stabilized
>  in the linux-media branch by -rc6.
>  
>  Review Cadence
>  --------------
>  
> -Provided that your patch is at https://patchwork.linuxtv.org, it should
> +Provided that your patch has landed in https://patchwork.linuxtv.org, it should
>  be sooner or later handled, so you don't need to re-submit a patch.
>  
> -Except for bug fixes, we don't usually add new patches to the development
> -tree between -rc6 and the next -rc1.
> +Except for important bug fixes, we don't usually add new patches to the
> +development tree between -rc6 and the next -rc1.
>  
>  Please notice that the media subsystem is a high traffic one, so it
>  could take a while for us to be able to review your patches. Feel free
>  to ping if you don't get a feedback in a couple of weeks or to ask
> -other developers to publicly add Reviewed-by and, more importantly,
> +other developers to publicly add ``Reviewed-by:`` and, more importantly,
>  ``Tested-by:`` tags.
>  
>  Please note that we expect a detailed description for ``Tested-by:``,
> -- 
> 2.51.0

Re: [PATCHv6 1/3] docs: media: update maintainer-entry-profile for multi-committers

[Hans Verkuil]

On 27/10/2025 23:06, Sean Young wrote:
> On Mon, Oct 27, 2025 at 02:28:31PM +0100, Hans Verkuil wrote:
>> From: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
>>
>> As the media subsystem will experiment with a multi-committers model,
>> update the Maintainer's entry profile to the new rules.
>>
>> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
>> Reviewed-by: Ricardo Ribalda <ribalda@chromium.org>
>> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
> 
> I've read it and I only have some tiny nits, looks great.

Thank you!

> 
> Reviewed-by: Sean Young <sean@mess.org>
> 

<snip>

>> +It could be wise to also copy the Media Maintainer(s). You should use
>> +``scripts/get_maintainers.pl`` to identify whom else needs to be copied.
>> +Please always copy driver's authors and maintainers.
> 
> git config for using scripts/get_maintainers.pl is useful
I'm not sure I understand what you meant with this.

Regards,

	Hans

Re: [PATCHv6 1/3] docs: media: update maintainer-entry-profile for multi-committers

[Sean Young]

On Tue, Oct 28, 2025 at 09:25:29AM +0100, Hans Verkuil wrote:
> On 27/10/2025 23:06, Sean Young wrote:
> > On Mon, Oct 27, 2025 at 02:28:31PM +0100, Hans Verkuil wrote:
> >> From: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
> >>
> >> As the media subsystem will experiment with a multi-committers model,
> >> update the Maintainer's entry profile to the new rules.
> >>
> >> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
> >> Reviewed-by: Ricardo Ribalda <ribalda@chromium.org>
> >> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
> > 
> > I've read it and I only have some tiny nits, looks great.
> 
> Thank you!
> 
> > 
> > Reviewed-by: Sean Young <sean@mess.org>
> > 
> 
> <snip>
> 
> >> +It could be wise to also copy the Media Maintainer(s). You should use
> >> +``scripts/get_maintainers.pl`` to identify whom else needs to be copied.
> >> +Please always copy driver's authors and maintainers.
> > 
> > git config for using scripts/get_maintainers.pl is useful
> I'm not sure I understand what you meant with this.

I should have been more specific. I use this in my .gitconfig:

[sendemail]
	tocmd ="scripts/get_maintainer.pl --no-git --no-git-fallback --no-l --no-roles --no-rolestats"
	cccmd ="scripts/get_maintainer.pl --no-git --no-git-fallback --no-m --no-roles --no-rolestats"

I find this very handy, I thought everyone was using this (possibly not).


Sean

[PATCHv6 2/3] docs: media: document media multi-committers rules and process

[Hans Verkuil]

From: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>

As the media subsystem will experiment with a multi-committers model,
update the Maintainer's entry profile to the new rules, and add a file
documenting the process to become a committer and to maintain such
rights.

Reviewed-by: Ricardo Ribalda <ribalda@chromium.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
---
 Documentation/driver-api/media/index.rst      |   1 +
 .../media/maintainer-entry-profile.rst        |  13 ++
 .../driver-api/media/media-committer.rst      | 196 ++++++++++++++++++
 3 files changed, 210 insertions(+)
 create mode 100644 Documentation/driver-api/media/media-committer.rst

diff --git a/Documentation/driver-api/media/index.rst b/Documentation/driver-api/media/index.rst
index d5593182a3f9..d0c725fcbc67 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-committer
 
     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 af499e79b23e..8238b4c36e62 100644
--- a/Documentation/driver-api/media/maintainer-entry-profile.rst
+++ b/Documentation/driver-api/media/maintainer-entry-profile.rst
@@ -171,6 +171,9 @@ 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 tree
 ----------------------
 
@@ -332,9 +335,19 @@ 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 sign, please read
 Documentation/process/maintainer-pgp-guide.rst.
 
+Maintaining media maintainer status
+-----------------------------------
+
+See :ref:`Maintain Media Status`.
+
 Subsystem Media Maintainers
 ---------------------------
 
diff --git a/Documentation/driver-api/media/media-committer.rst b/Documentation/driver-api/media/media-committer.rst
new file mode 100644
index 000000000000..23f372d2c3b3
--- /dev/null
+++ b/Documentation/driver-api/media/media-committer.rst
@@ -0,0 +1,196 @@
+.. _Media Committers:
+
+Media Committers
+================
+
+Who is a Media Committer?
+-------------------------
+
+A Media Committer is a Media Maintainer 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.
+
+.. Note::
+
+   1. Patches you authored must have a Signed-off-by, Reviewed-by or Acked-by
+      of another Media Maintainer;
+   2. If a patch introduces a regression, then it is the Media Committer's
+      responsibility to correct that 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 above mentioned, the Media Committer shall add the needed
+      tags. Please see :ref:`Media development workflow` for more details.
+
+Becoming a Media Committer
+--------------------------
+
+Existing Media Committers can nominate a Media Maintainer to be granted
+commit rights. The Media Maintainer must have been in that role 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 are already
+maintained by the nominated committer.
+
+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-committer's 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-committer.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-committer tree, I understand that I agree
+   to follow the rules in effect at the time of the commit.
+
+That e-mail shall be signed 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-committer.git tree.
+
+In case the kernel development process changes, by merging new commits
+to the
+`media-committer 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 mailinglist with a reasonable review period. All
+      committers are automatically subscribed to that mailinglist;
+   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 mailing list, specially for the
+      contents under Documentation/process and for trivial typo fixes.
+
+Media Core Committers
+---------------------
+
+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 able to change core files and the media subsystem's
+Kernel API. A Media Core Committer is a Media Core Maintainer with commit
+rights. 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 between 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, specially 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
+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 subsystem maintainer
+not trusting the media maintainer or committer anymore is enough to revoke
+the maintenance or commit rights.
+
+A previous committer that had their commit rights revoked can keep
+contributing to the subsystem via the pull request workflow as documented
+at the :ref:`Media development workflow`, unless they were also removed as
+Media Maintainer.
+
+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 your maintainer and committer rights and update MAINTAINERS file
+entries accordingly. If you wish to resume contributing later on, then contact
+the Media Subsystem Maintainers to ask if your maintenance 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/>`_.
-- 
2.51.0

[PATCHv6 3/3] docs: media: document Media Maintainers

[Hans Verkuil]

Document who the Media Maintainers are and what their
responsibilities are.

Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
---
 .../media/maintainer-entry-profile.rst        | 40 +++++++++++++++++--
 1 file changed, 37 insertions(+), 3 deletions(-)

diff --git a/Documentation/driver-api/media/maintainer-entry-profile.rst b/Documentation/driver-api/media/maintainer-entry-profile.rst
index 8238b4c36e62..09ccd3e6626a 100644
--- a/Documentation/driver-api/media/maintainer-entry-profile.rst
+++ b/Documentation/driver-api/media/maintainer-entry-profile.rst
@@ -348,13 +348,47 @@ Maintaining media maintainer status
 
 See :ref:`Maintain Media Status`.
 
-Subsystem Media Maintainers
----------------------------
+List of Media Maintainers
+-------------------------
 
-The subsystem maintainers are:
+The Media Subsystem Maintainers are:
   - Mauro Carvalho Chehab <mchehab@kernel.org>
   - Hans Verkuil <hverkuil@kernel.org>
 
+The Media Core Maintainers are:
+  - Sakari Ailus <sakari.ailus@linux.intel.com>
+
+    - ISP
+    - sensor drivers
+    - v4l2-async and v4l2-fwnode core frameworks
+    - v4l2-flash-led-class core framework
+
+  - Mauro Carvalho Chehab <mchehab@kernel.org>
+
+    - DVB
+  - Laurent Pinchart <laurent.pinchart@ideasonboard.com>
+
+    - Media controller drivers
+    - Core media controller framework
+  - Hans Verkuil <hverkuil@kernel.org>
+
+    - V4L2 drivers
+    - V4L2 and videobuf2 core frameworks
+    - HDMI CEC drivers
+    - HDMI CEC core framework
+  - Sean Young <sean@mess.org>
+
+    - Remote Controller (infrared) drivers
+    - Remote Controller (infrared) core framework
+
+The Media Maintainers are:
+  - Nicolas Dufresne <nicolas.dufresne@collabora.com>
+
+    - Codec drivers
+  - Bryan O'Donoghue <bryan.odonoghue@linaro.org>
+
+    - Qualcomm drivers
+
 Submit Checklist Addendum
 -------------------------
 
-- 
2.51.0