| 1 | |
| 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 | |
| 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 [email protected], 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/>`_.
|