Documentation/driver-api/media/media-committers.rst - pub/scm/linux/kernel/git/next/linux-next - Git at Google

 .. 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.

 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-committers 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-committers.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-committers tree, I understand that I agree
    to follow the rules in effect at the time of the commit.

 That e-mail shall be signed via the Kernel Web of trust 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-committers.git tree.

 In case the kernel development process changes, by merging new commits to the
 `media-committers 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 mailing list with a reasonable review period. All
       committers are automatically subscribed to that mailing list;
    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 and/or at the Linux Kernel mailing
       lists, especially for the contents under Documentation/process and for
       trivial typo fixes.

 Media Core Committers
 ---------------------

 A Media Core Committer is a Media Core Maintainer with commit rights.

 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 allowed to change core files and the media subsystem's
 Kernel API. 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 among 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, especially 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
 Media Subsystem 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 Media Subsystem
 Maintainer not trusting the Media Maintainer or Committer anymore is enough
 to revoke their maintenance, Patchwork grants and/or commit rights.

 Having commit rights revoked doesn't prevent Media Maintainers to keep
 contributing to the subsystem either via the pull request or via email workflow
 as documented at the :ref:`Media development workflow`.

 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 their maintainer/patchwork and committer rights and update MAINTAINERS
 file entries accordingly. If you wish to resume contributing as maintainer
 later on, then contact the Media Subsystem Maintainers to ask if your
 maintenance, Patchwork grants 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/>`_.
	.. 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.

	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-committers 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-committers.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-committers tree, I understand that I agree
	to follow the rules in effect at the time of the commit.

	That e-mail shall be signed via the Kernel Web of trust 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-committers.git tree.

	In case the kernel development process changes, by merging new commits to the
	`media-committers 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 mailing list with a reasonable review period. All
	committers are automatically subscribed to that mailing list;
	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 and/or at the Linux Kernel mailing
	lists, especially for the contents under Documentation/process and for
	trivial typo fixes.

	Media Core Committers
	---------------------

	A Media Core Committer is a Media Core Maintainer with commit rights.

	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 allowed to change core files and the media subsystem's
	Kernel API. 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 among 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, especially 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
	Media Subsystem 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 Media Subsystem
	Maintainer not trusting the Media Maintainer or Committer anymore is enough
	to revoke their maintenance, Patchwork grants and/or commit rights.

	Having commit rights revoked doesn't prevent Media Maintainers to keep
	contributing to the subsystem either via the pull request or via email workflow
	as documented at the :ref:`Media development workflow`.

	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 their maintainer/patchwork and committer rights and update MAINTAINERS
	file entries accordingly. If you wish to resume contributing as maintainer
	later on, then contact the Media Subsystem Maintainers to ask if your
	maintenance, Patchwork grants 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/>`_.