- 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_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.
- 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
build_options_examples
to perform checks like checkpatch, checkspdx, header files include order etc.
- Use the static checks as shown in
- Where appropriate, please update the documentation.
- Consider whether the
Design
document or other in-source documentation needs updating.
- Consider whether the
- 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.
Assuming the clone of the repo has been done as mentioned in the
getting_started_get_source
and origin refers to the upstream repo, submit your changes for review targeting theintegration
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.
- At least one maintainer. See the list of
- 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 theintegration
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 theintegration
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, themaintainers
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.
- Typically, the
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 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 :
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.