Documentation/driver-api/media/media-committers.rst
Source file repositories/reference/linux-study-clean/Documentation/driver-api/media/media-committers.rst
File Facts
- System
- Linux kernel
- Corpus path
Documentation/driver-api/media/media-committers.rst- Extension
.rst- Size
- 9117 bytes
- Lines
- 204
- Domain
- Support Tooling And Documentation
- Bucket
- Documentation
- Inferred role
- Support Tooling And Documentation: documentation
- Status
- atlas-only
Why This File Exists
Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.
- Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.
Dependency Surface
- No C-style include directives detected by the generator.
Detected Declarations
- No top-level syscall, struct, function, initcall, or export declaration detected by the generator.
Annotated Snippet
.. 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.
Annotation
- Atlas domain: Support Tooling And Documentation / Documentation.
- Implementation status: atlas-only.
Implementation Notes
- This generated page is the file-by-file coverage layer; curated subsystem chapters should link here when they synthesize a multi-file control flow.
- Core OS pages should be promoted from atlas-only to deep-reviewed when they explain data structures, invariants, locking, lifecycle, and C implementation snippets.
- Driver-family pages are intentionally pattern-oriented unless they are part of the selected PCIe/NVMe representative device path.