.. 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=] 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/