Linux kernel mirror (for testing)
git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
kernel
os
linux
docs: media: document media multi-committers rules and process
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>
Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
+225
+1
Documentation/driver-api/media/index.rst
+1
Documentation/driver-api/media/index.rst
+21
Documentation/driver-api/media/maintainer-entry-profile.rst
+21
Documentation/driver-api/media/maintainer-entry-profile.rst
···
176
176
relationship with all Media Subsystem Maintainers, as, by being granted
177
177
Patchwork access, you will take over part of their maintenance tasks.
178
178
179
+
Media Committers
180
+
----------------
181
+
182
+
Experienced and trusted Media Maintainers may be granted commit rights
183
+
which allow them to directly push patches to the media development tree instead
184
+
of posting a Pull Request for the Media Subsystem Maintainers. This helps
185
+
offloading some of the work of the Media Subsystem Maintainers.
186
+
187
+
More details about Media Committers' roles and responsibilities can be
188
+
found here: :ref:`Media Committers`.
189
+
179
190
Media development sites
180
191
-----------------------
181
192
···
367
356
368
357
With the Pull Request workflow, Pull Requests shall use PGP-signed tags.
369
358
359
+
With the committers' workflow, this is ensured at the time merge request
360
+
rights will be granted to the gitlab instance used by the media-committers.git
361
+
tree, after receiving the e-mail documented in
362
+
:ref:`media-committer-agreement`.
363
+
370
364
For more details about PGP signing, please read
371
365
Documentation/process/maintainer-pgp-guide.rst.
366
+
367
+
Maintaining media maintainer status
368
+
-----------------------------------
369
+
370
+
See :ref:`Maintain Media Status`.
372
371
373
372
List of Media Maintainers
374
373
-------------------------
+203
Documentation/driver-api/media/media-committers.rst
+203
Documentation/driver-api/media/media-committers.rst
···
1
+
.. SPDX-License-Identifier: GPL-2.0
2
+
3
+
.. _Media Committers:
4
+
5
+
Media Committers
6
+
================
7
+
8
+
Who is a Media Committer?
9
+
-------------------------
10
+
11
+
A Media Committer is a Media Maintainer with patchwork access who has been
12
+
granted commit access to push patches from other developers and their own
13
+
patches to the
14
+
`media-committers <https://gitlab.freedesktop.org/linux-media/media-committers>`_
15
+
tree.
16
+
17
+
These commit rights are granted with expectation of responsibility:
18
+
committers are people who care about the Linux Kernel as a whole and
19
+
about the Linux media subsystem and want to advance its development. It
20
+
is also based on a trust relationship among other committers, maintainers
21
+
and the Linux Media community.
22
+
23
+
As Media Committer you have the following additional responsibilities:
24
+
25
+
1. Patches you authored must have a ``Signed-off-by``, ``Reviewed-by``
26
+
or ``Acked-by`` from another Media Maintainer;
27
+
2. 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;
30
+
3. 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.
33
+
4. 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
+
38
+
Becoming a Media Committer
39
+
--------------------------
40
+
41
+
Existing Media Committers can nominate a Media Maintainer to be granted
42
+
commit rights. The Media Maintainer must have patchwork access,
43
+
have been reviewing patches from third parties for some time, and has
44
+
demonstrated a good understanding of the maintainer's duties and processes.
45
+
46
+
The ultimate responsibility for accepting a nominated committer is up to
47
+
the Media Subsystem Maintainers. The nominated committer must have earned a
48
+
trust relationship with all Media Subsystem Maintainers, as, by granting you
49
+
commit rights, part of their responsibilities are handed over to you.
50
+
51
+
Due to that, to become a Media Committer, a consensus between all Media
52
+
Subsystem 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
+
63
+
Media Committer's agreement
64
+
---------------------------
65
+
66
+
Once a nominated committer is accepted by all Media Subsystem Maintainers,
67
+
they will ask if the developer is interested in the nomination and discuss
68
+
what area(s) of the media subsystem the committer will be responsible for.
69
+
Those areas will typically be the same as the areas that the nominated
70
+
committer is already maintaining.
71
+
72
+
When the developer accepts being a committer, the new committer shall
73
+
explicitly accept the Kernel development policies described under its
74
+
Documentation/, and in particular to the rules in this document, by writing
75
+
an e-mail to media-committers@linuxtv.org, with a declaration of intent
76
+
following 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
+
88
+
Followed by a formal declaration of agreement with the Kernel development
89
+
rules::
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
+
108
+
That e-mail shall be signed via the Kernel Web of trust with a PGP key cross
109
+
signed by other Kernel and media developers. As described at
110
+
:ref:`media-developers-gpg`, the PGP signature, together with the gitlab user
111
+
security are fundamental components that ensure the authenticity of the merge
112
+
requests that will happen at the media-committers.git tree.
113
+
114
+
In case the kernel development process changes, by merging new commits to the
115
+
`media-committers tree <https://gitlab.freedesktop.org/linux-media/media-committers>`_,
116
+
the Media Committer implicitly declares their agreement with the latest
117
+
version of the documented process including the contents of this file.
118
+
119
+
If a Media Committer decides to retire, it is the committer's duty to
120
+
notify 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
+
133
+
Media Core Committers
134
+
---------------------
135
+
136
+
A Media Core Committer is a Media Core Maintainer with commit rights.
137
+
138
+
As described in Documentation/driver-api/media/maintainer-entry-profile.rst,
139
+
a Media Core Maintainer maintains media core frameworks as well, besides
140
+
just drivers, and so is allowed to change core files and the media subsystem's
141
+
Kernel API. The extent of the core committer's grants will be detailed by the
142
+
Media Subsystem Maintainers when they nominate a Media Core Committer.
143
+
144
+
Existing Media Committers may become Media Core Committers and vice versa.
145
+
Such decisions will be taken in consensus among the Media Subsystem
146
+
Maintainers.
147
+
148
+
Media committers rules
149
+
----------------------
150
+
151
+
Media committers shall do their best efforts to avoid merging patches that
152
+
would break any existing drivers. If it breaks, fixup or revert patches
153
+
shall be merged as soon as possible, aiming to be merged at the same Kernel
154
+
cycle the bug is reported.
155
+
156
+
Media committers shall behave accordingly to the rights granted by
157
+
the Media Subsystem Maintainers, especially with regards of the scope of changes
158
+
they may apply directly at the media-committers tree. That scope can
159
+
change over time on a mutual agreement between Media Committers and
160
+
Media Subsystem Maintainers.
161
+
162
+
The Media Committer workflow is described at :ref:`Media development workflow`.
163
+
164
+
.. _Maintain Media Status:
165
+
166
+
Maintaining Media Maintainer or Committer status
167
+
------------------------------------------------
168
+
169
+
A community of maintainers working together to move the Linux Kernel
170
+
forward is essential to creating successful projects that are rewarding
171
+
to work on. If there are problems or disagreements within the community,
172
+
they can usually be solved through healthy discussion and debate.
173
+
174
+
In the unhappy event that a Media Maintainer or Committer continues to
175
+
disregard good citizenship (or actively disrupts the project), we may need
176
+
to revoke that person's status. In such cases, if someone suggests the
177
+
revocation with a good reason, then after discussing this among the Media
178
+
Maintainers, the final decision is taken by the Media Subsystem Maintainers.
179
+
180
+
As the decision to become a Media Maintainer or Committer comes from a
181
+
consensus between Media Subsystem Maintainers, a single Media Subsystem
182
+
Maintainer not trusting the Media Maintainer or Committer anymore is enough
183
+
to revoke their maintenance, Patchwork grants and/or commit rights.
184
+
185
+
Having commit rights revoked doesn't prevent Media Maintainers to keep
186
+
contributing to the subsystem either via the pull request or via email workflow
187
+
as documented at the :ref:`Media development workflow`.
188
+
189
+
If a maintainer is inactive for more than a couple of Kernel cycles,
190
+
maintainers will try to reach you via e-mail. If not possible, they may
191
+
revoke their maintainer/patchwork and committer rights and update MAINTAINERS
192
+
file entries accordingly. If you wish to resume contributing as maintainer
193
+
later on, then contact the Media Subsystem Maintainers to ask if your
194
+
maintenance, Patchwork grants and commit rights can be restored.
195
+
196
+
References
197
+
----------
198
+
199
+
Much 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/>`_.