docs/process/contributing.rst - TF-RMM/tf-rmm - TrustedFirmware Git Browser

 .. SPDX-License-Identifier: BSD-3-Clause
 .. SPDX-FileCopyrightText: Copyright TF-RMM Contributors.

 *******************
 Contributor's Guide
 *******************

 Getting Started
 ===============

 -  Make sure you have a Github account and you are logged on
    `review.trustedfirmware.org`_.

 -  Clone `RMM`_ on your own machine as described in
    :ref:`getting_started_get_source`.

 -  If you plan to contribute a major piece of work, it is usually a good idea to
    start a discussion around it on the mailing list. This gives everyone
    visibility of what is coming up, you might learn that somebody else is
    already working on something similar or the community might be able to
    provide some early input to help shaping the design of the feature.

 -  If you intend to include Third Party IP in your contribution, please mention
    it explicitly in the email thread and ensure that the changes that include
    Third Party IP are made in a separate patch (or patch series).

 -  Create a local topic branch based on the `RMM`_ ``main`` branch.

 Making Changes
 ==============

 -  See the `License and Copyright for Contributions`_ section for guidance
    on license and copyright.

 -  Ensure commits adhere to the project's :ref:`Commit Style`.

 -  Make commits of logical units. See these general `Git guidelines`_ for
    contributing to a project.

 -  Keep the commits on topic. If you need to fix another bug or make another
    enhancement, please address it on a separate topic branch.

 -  Split the patch into manageable units. Small patches are usually easier to
    review so this will speed up the review process.

 -  Avoid long commit series. If you do have a long series, consider whether
    some commits should be squashed together or addressed in a separate topic.

 -  Follow the :ref:`Coding Standard`.

 -  Use the static checks as shown in :ref:`build_options_examples` to perform
    checks like checkpatch, checkspdx, header files include order, clang-tidy,
    cppcheck etc. A sample static analysis command line is given below, assuming
    the tools have been setup as per instruction in :ref:`getting_started`.

    .. code-block:: bash

       cd $rmm_root
       cmake -DRMM_CONFIG=fvp_defcfg -S . -B build -DRMM_TOOLCHAIN=llvm -DCMAKE_EXPORT_COMPILE_COMMANDS=ON
       cmake --build build -- checkpatch checkspdx-patch checkincludes-patch clang-tidy-patch cppcheck-misra

 -  Where appropriate, please update the documentation.

    -  Consider whether the :ref:`Design` document or other in-source
       documentation needs updating.

 -  Ensure that each patch in the patch series compiles in all supported
    configurations. For generic changes, such as on the libraries, The
    :ref:`RMM Fake host architecture` should be able to, at least,
    build. Patches which do not compile will not be merged.

 -  Please test your changes and add suitable tests in the available test
    frameworks for any new functionality.

 Submitting Changes
 ==================

 -  Assuming the clone of the repo has been done as mentioned in the
    :ref:`getting_started_get_source` and *origin* refers to the upstream repo,
    submit your changes for review targeting the ``integration`` branch.
    Create a topic that describes the target of your changes to help group
    related patches together.

    .. code::

        git push origin HEAD:refs/for/integration [-o topic=<your_topic>]

    Refer to the `Gerrit Uploading Changes documentation`_ for more details.

 -  Add reviewers for your patch:

    -  At least one maintainer. See the list of :ref:`maintainers`.

    -  Alternatively, you might send an email to the `TF-RMM mailing list`_
       to broadcast your review request to the community.

 -  The changes will then undergo further review by the designated people. Any
    review comments will be made directly on your patch. This may require you to
    do some rework. For controversial changes, the discussion might be moved to
    the `TF-RMM mailing list`_ to involve more of the community.

 -  The patch submission rules are the following. For a patch to be approved
    and merged in the tree, it must get a ``Code-Review+2``.

    In addition to that, the patch must also get a ``Verified+1``. This is
    usually set by the Continuous Integration (CI) bot when all automated tests
    passed on the patch. Sometimes, some of these automated tests may fail for
    reasons unrelated to the patch. In this case, the maintainers might
    (after analysis of the failures) override the CI bot score to certify that
    the patch has been correctly tested.

    In the event where the CI system lacks proper tests for a patch, the patch
    author or a reviewer might agree to perform additional manual tests
    in their review and the reviewer incorporates the review of the additional
    testing in the ``Code-Review+1`` to attest that the patch works as expected.

 -  When the changes are accepted, the :ref:`maintainers` will integrate them.

    -  Typically, the :ref:`maintainers` will merge the changes into the
       ``integration`` branch.

    -  If the changes are not based on a sufficiently-recent commit, or if they
       cannot be automatically rebased, then the :ref:`maintainers` may rebase it
       on the ``integration`` branch or ask you to do so.

    -  After final integration testing, the changes will make their way into the
       ``main`` branch. If a problem is found during integration, the
       :ref:`maintainers` will request your help to solve the issue. They may
       revert your patches and ask you to resubmit a reworked version of them or
       they may ask you to provide a fix-up patch.

 .. _copyright-license-guidance:

 License and Copyright for Contributions
 =======================================

 All new files should include the BSD-3-Clause SPDX license identifier
 where possible. When contributing code to us, the committer and all authors
 are required to make the submission under the terms of the
 :ref:`Developer Certificate of Origin`, confirming that the code submitted can
 (legally) become part of the project, and be subject to the same BSD-3-Clause
 license. This is done by including the standard Git ``Signed-off-by:``
 line in every commit message. If more than one person contributed to the
 commit, they should also add their own ``Signed-off-by:`` line.

 Files that entirely consist of contributions to this project should
 have a copyright notice and BSD-3-Clause SPDX license identifier of
 the form :

 .. code::

    SPDX-License-Identifier: BSD-3-Clause
    SPDX-FileCopyrightText: Copyright TF-RMM Contributors.

 Patches that contain changes to imported Third Party IP files should retain
 their original copyright and license notices. If changes are made to the
 imported files, then add an additional ``SPDX-FileCopyrightText`` tag line
 as shown above.

 --------------

 .. _review.trustedfirmware.org: https://review.trustedfirmware.org
 .. _RMM: https://git.trustedfirmware.org/TF-RMM/tf-rmm.git
 .. _Git guidelines: http://git-scm.com/book/ch5-2.html
 .. _Gerrit Uploading Changes documentation: https://review.trustedfirmware.org/Documentation/user-upload.html
 .. _TF-A Tests: https://trustedfirmware-a-tests.readthedocs.io
 .. _TF-RMM mailing list: https://lists.trustedfirmware.org/mailman3/lists/tf-rmm.lists.trustedfirmware.org/
	.. SPDX-License-Identifier: BSD-3-Clause
	.. SPDX-FileCopyrightText: Copyright TF-RMM Contributors.

	*******************
	Contributor's Guide
	*******************

	Getting Started
	===============

	- Make sure you have a Github account and you are logged on
	`review.trustedfirmware.org`_.

	- Clone `RMM`_ on your own machine as described in
	:ref:`getting_started_get_source`.

	- If you plan to contribute a major piece of work, it is usually a good idea to
	start a discussion around it on the mailing list. This gives everyone
	visibility of what is coming up, you might learn that somebody else is
	already working on something similar or the community might be able to
	provide some early input to help shaping the design of the feature.

	- If you intend to include Third Party IP in your contribution, please mention
	it explicitly in the email thread and ensure that the changes that include
	Third Party IP are made in a separate patch (or patch series).

	- Create a local topic branch based on the `RMM`_ ``main`` branch.

	Making Changes
	==============

	- See the `License and Copyright for Contributions`_ section for guidance
	on license and copyright.

	- Ensure commits adhere to the project's :ref:`Commit Style`.

	- Make commits of logical units. See these general `Git guidelines`_ for
	contributing to a project.

	- Keep the commits on topic. If you need to fix another bug or make another
	enhancement, please address it on a separate topic branch.

	- Split the patch into manageable units. Small patches are usually easier to
	review so this will speed up the review process.

	- Avoid long commit series. If you do have a long series, consider whether
	some commits should be squashed together or addressed in a separate topic.

	- Follow the :ref:`Coding Standard`.

	- Use the static checks as shown in :ref:`build_options_examples` to perform
	checks like checkpatch, checkspdx, header files include order, clang-tidy,
	cppcheck etc. A sample static analysis command line is given below, assuming
	the tools have been setup as per instruction in :ref:`getting_started`.

	.. code-block:: bash

	cd $rmm_root
	cmake -DRMM_CONFIG=fvp_defcfg -S . -B build -DRMM_TOOLCHAIN=llvm -DCMAKE_EXPORT_COMPILE_COMMANDS=ON
	cmake --build build -- checkpatch checkspdx-patch checkincludes-patch clang-tidy-patch cppcheck-misra

	- Where appropriate, please update the documentation.

	- Consider whether the :ref:`Design` document or other in-source
	documentation needs updating.

	- Ensure that each patch in the patch series compiles in all supported
	configurations. For generic changes, such as on the libraries, The
	:ref:`RMM Fake host architecture` should be able to, at least,
	build. Patches which do not compile will not be merged.

	- Please test your changes and add suitable tests in the available test
	frameworks for any new functionality.

	Submitting Changes
	==================

	- Assuming the clone of the repo has been done as mentioned in the
	:ref:`getting_started_get_source` and origin refers to the upstream repo,
	submit your changes for review targeting the ``integration`` branch.
	Create a topic that describes the target of your changes to help group
	related patches together.

	.. code::

	git push origin HEAD:refs/for/integration [-o topic=<your_topic>]

	Refer to the `Gerrit Uploading Changes documentation`_ for more details.

	- Add reviewers for your patch:

	- At least one maintainer. See the list of :ref:`maintainers`.

	- Alternatively, you might send an email to the `TF-RMM mailing list`_
	to broadcast your review request to the community.

	- The changes will then undergo further review by the designated people. Any
	review comments will be made directly on your patch. This may require you to
	do some rework. For controversial changes, the discussion might be moved to
	the `TF-RMM mailing list`_ to involve more of the community.

	- The patch submission rules are the following. For a patch to be approved
	and merged in the tree, it must get a ``Code-Review+2``.

	In addition to that, the patch must also get a ``Verified+1``. This is
	usually set by the Continuous Integration (CI) bot when all automated tests
	passed on the patch. Sometimes, some of these automated tests may fail for
	reasons unrelated to the patch. In this case, the maintainers might
	(after analysis of the failures) override the CI bot score to certify that
	the patch has been correctly tested.

	In the event where the CI system lacks proper tests for a patch, the patch
	author or a reviewer might agree to perform additional manual tests
	in their review and the reviewer incorporates the review of the additional
	testing in the ``Code-Review+1`` to attest that the patch works as expected.

	- When the changes are accepted, the :ref:`maintainers` will integrate them.

	- Typically, the :ref:`maintainers` will merge the changes into the
	``integration`` branch.

	- If the changes are not based on a sufficiently-recent commit, or if they
	cannot be automatically rebased, then the :ref:`maintainers` may rebase it
	on the ``integration`` branch or ask you to do so.

	- After final integration testing, the changes will make their way into the
	``main`` branch. If a problem is found during integration, the
	:ref:`maintainers` will request your help to solve the issue. They may
	revert your patches and ask you to resubmit a reworked version of them or
	they may ask you to provide a fix-up patch.

	.. _copyright-license-guidance:

	License and Copyright for Contributions
	=======================================

	All new files should include the BSD-3-Clause SPDX license identifier
	where possible. When contributing code to us, the committer and all authors
	are required to make the submission under the terms of the
	:ref:`Developer Certificate of Origin`, confirming that the code submitted can
	(legally) become part of the project, and be subject to the same BSD-3-Clause
	license. This is done by including the standard Git ``Signed-off-by:``
	line in every commit message. If more than one person contributed to the
	commit, they should also add their own ``Signed-off-by:`` line.

	Files that entirely consist of contributions to this project should
	have a copyright notice and BSD-3-Clause SPDX license identifier of
	the form :

	.. code::

	SPDX-License-Identifier: BSD-3-Clause
	SPDX-FileCopyrightText: Copyright TF-RMM Contributors.

	Patches that contain changes to imported Third Party IP files should retain
	their original copyright and license notices. If changes are made to the
	imported files, then add an additional ``SPDX-FileCopyrightText`` tag line
	as shown above.

	--------------

	.. _review.trustedfirmware.org: https://review.trustedfirmware.org
	.. _RMM: https://git.trustedfirmware.org/TF-RMM/tf-rmm.git
	.. _Git guidelines: http://git-scm.com/book/ch5-2.html
	.. _Gerrit Uploading Changes documentation: https://review.trustedfirmware.org/Documentation/user-upload.html
	.. _TF-A Tests: https://trustedfirmware-a-tests.readthedocs.io
	.. _TF-RMM mailing list: https://lists.trustedfirmware.org/mailman3/lists/tf-rmm.lists.trustedfirmware.org/