4. Contributor’s Guide

4.1. 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 Getting the RMM 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.

4.2. Making Changes

  • See the License and Copyright for Contributions section for guidance on license and copyright.

  • Ensure commits adhere to the project’s 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 Coding Standard.

    • Use the static checks as shown in RMM Build Examples to perform checks like checkpatch, checkspdx, header files include order etc.

  • Where appropriate, please update the documentation.

    • Consider whether the 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 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.

  • Ensure that all CI automated tests pass. Failures should be fixed. They might block a patch, depending on how critical they are.

4.3. Submitting Changes

  • Assuming the clone of the repo has been done as mentioned in the Getting the RMM 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.

    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 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 Maintainers will integrate them.

    • Typically, the 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 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 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.