xref: /linux/Documentation/driver-api/media/media-committers.rst (revision e2683c8868d03382da7e1ce8453b543a043066d1)
1.. SPDX-License-Identifier: GPL-2.0
2
3.. _Media Committers:
4
5Media Committers
6================
7
8Who is a Media Committer?
9-------------------------
10
11A Media Committer is a Media Maintainer with patchwork access who has been
12granted commit access to push patches from other developers and their own
13patches to the
14`media-committers <https://gitlab.freedesktop.org/linux-media/media-committers>`_
15tree.
16
17These commit rights are granted with expectation of responsibility:
18committers are people who care about the Linux Kernel as a whole and
19about the Linux media subsystem and want to advance its development. It
20is also based on a trust relationship among other committers, maintainers
21and the Linux Media community.
22
23As Media Committer you have the following additional responsibilities:
24
251. Patches you authored must have a ``Signed-off-by``, ``Reviewed-by``
26   or ``Acked-by`` from another Media Maintainer;
272. If a patch introduces a regression, then that must be corrected as soon
28   as possible. Typically the patch is either reverted, or an additional
29   patch is committed to fix the regression;
303. If patches are fixing bugs against already released Kernels, including
31   the reverts mentioned above, the Media Committer shall add the needed
32   tags. Please see :ref:`Media development workflow` for more details.
334. All Media Committers are responsible for maintaining
34   `Patchwork <https://patchwork.linuxtv.org/project/linux-media/list/>`_,
35   updating the state of the patches they review or merge.
36
37
38Becoming a Media Committer
39--------------------------
40
41Existing Media Committers can nominate a Media Maintainer to be granted
42commit rights. The Media Maintainer must have patchwork access,
43have been reviewing patches from third parties for some time, and has
44demonstrated a good understanding of the maintainer's duties and processes.
45
46The ultimate responsibility for accepting a nominated committer is up to
47the Media Subsystem Maintainers. The nominated committer must have earned a
48trust relationship with all Media Subsystem Maintainers, as, by granting you
49commit rights, part of their responsibilities are handed over to you.
50
51Due to that, to become a Media Committer, a consensus between all Media
52Subsystem Maintainers is required.
53
54.. Note::
55
56   In order to preserve/protect the developers that could have their commit
57   rights granted, denied or removed as well as the subsystem maintainers who
58   have the task to accept or deny commit rights, all communication related to
59   changing commit rights should happen in private as much as possible.
60
61.. _media-committer-agreement:
62
63Media Committer's agreement
64---------------------------
65
66Once a nominated committer is accepted by all Media Subsystem Maintainers,
67they will ask if the developer is interested in the nomination and discuss
68what area(s) of the media subsystem the committer will be responsible for.
69Those areas will typically be the same as the areas that the nominated
70committer is already maintaining.
71
72When the developer accepts being a committer, the new committer shall
73explicitly accept the Kernel development policies described under its
74Documentation/, and in particular to the rules in this document, by writing
75an e-mail to media-committers@linuxtv.org, with a declaration of intent
76following the model below::
77
78   I, John Doe, would like to change my status to: Committer
79
80   As Media Maintainer I accept commit rights for the following areas of
81   the media subsystem:
82
83   ...
84
85   For the purpose of committing patches to the media-committers tree,
86   I'll be using my user https://gitlab.freedesktop.org/users/<username>.
87
88Followed by a formal declaration of agreement with the Kernel development
89rules::
90
91   I agree to follow the Kernel development rules described at:
92
93   https://www.kernel.org/doc/html/latest/driver-api/media/media-committers.rst
94
95   and to the Linux Kernel development process rules.
96
97   I agree to abide by the Code of Conduct as documented in:
98   https://www.kernel.org/doc/html/latest/process/code-of-conduct.rst
99
100   I am aware that I can, at any point of time, retire. In that case, I will
101   send an e-mail to notify the Media Subsystem Maintainers for them to revoke
102   my commit rights.
103
104   I am aware that the Kernel development rules change over time.
105   By doing a new push to media-committers tree, I understand that I agree
106   to follow the rules in effect at the time of the commit.
107
108That e-mail shall be signed via the Kernel Web of trust with a PGP key cross
109signed by other Kernel and media developers. As described at
110:ref:`media-developers-gpg`, the PGP signature, together with the gitlab user
111security are fundamental components that ensure the authenticity of the merge
112requests that will happen at the media-committers.git tree.
113
114In case the kernel development process changes, by merging new commits to the
115`media-committers tree <https://gitlab.freedesktop.org/linux-media/media-committers>`_,
116the Media Committer implicitly declares their agreement with the latest
117version of the documented process including the contents of this file.
118
119If a Media Committer decides to retire, it is the committer's duty to
120notify the Media Subsystem Maintainers about that decision.
121
122.. note::
123
124   1. Changes to the kernel media development process shall be announced in
125      the media-committers mailing list with a reasonable review period. All
126      committers are automatically subscribed to that mailing list;
127   2. Due to the distributed nature of the Kernel development, it is
128      possible that kernel development process changes may end being
129      reviewed/merged at the Linux Docs and/or at the Linux Kernel mailing
130      lists, especially for the contents under Documentation/process and for
131      trivial typo fixes.
132
133Media Core Committers
134---------------------
135
136A Media Core Committer is a Media Core Maintainer with commit rights.
137
138As described in Documentation/driver-api/media/maintainer-entry-profile.rst,
139a Media Core Maintainer maintains media core frameworks as well, besides
140just drivers, and so is allowed to change core files and the media subsystem's
141Kernel API. The extent of the core committer's grants will be detailed by the
142Media Subsystem Maintainers when they nominate a Media Core Committer.
143
144Existing Media Committers may become Media Core Committers and vice versa.
145Such decisions will be taken in consensus among the Media Subsystem
146Maintainers.
147
148Media committers rules
149----------------------
150
151Media committers shall do their best efforts to avoid merging patches that
152would break any existing drivers. If it breaks, fixup or revert patches
153shall be merged as soon as possible, aiming to be merged at the same Kernel
154cycle the bug is reported.
155
156Media committers shall behave accordingly to the rights granted by
157the Media Subsystem Maintainers, especially with regards of the scope of changes
158they may apply directly at the media-committers tree. That scope can
159change over time on a mutual agreement between Media Committers and
160Media Subsystem Maintainers.
161
162The Media Committer workflow is described at :ref:`Media development workflow`.
163
164.. _Maintain Media Status:
165
166Maintaining Media Maintainer or Committer status
167------------------------------------------------
168
169A community of maintainers working together to move the Linux Kernel
170forward is essential to creating successful projects that are rewarding
171to work on. If there are problems or disagreements within the community,
172they can usually be solved through healthy discussion and debate.
173
174In the unhappy event that a Media Maintainer or Committer continues to
175disregard good citizenship (or actively disrupts the project), we may need
176to revoke that person's status. In such cases, if someone suggests the
177revocation with a good reason, then after discussing this among the Media
178Maintainers, the final decision is taken by the Media Subsystem Maintainers.
179
180As the decision to become a Media Maintainer or Committer comes from a
181consensus between Media Subsystem Maintainers, a single Media Subsystem
182Maintainer not trusting the Media Maintainer or Committer anymore is enough
183to revoke their maintenance, Patchwork grants and/or commit rights.
184
185Having commit rights revoked doesn't prevent Media Maintainers to keep
186contributing to the subsystem either via the pull request or via email workflow
187as documented at the :ref:`Media development workflow`.
188
189If a maintainer is inactive for more than a couple of Kernel cycles,
190maintainers will try to reach you via e-mail. If not possible, they may
191revoke their maintainer/patchwork and committer rights and update MAINTAINERS
192file entries accordingly. If you wish to resume contributing as maintainer
193later on, then contact the Media Subsystem Maintainers to ask if your
194maintenance, Patchwork grants and commit rights can be restored.
195
196References
197----------
198
199Much of this was inspired by/copied from the committer policies of:
200
201- `Chromium <https://chromium.googlesource.com/chromium/src/+/main/docs/contributing.md>`_;
202- `WebKit <https://webkit.org/commit-and-review-policy/>`_;
203- `Mozilla <https://www.mozilla.org/hacking/committer/>`_.
204