Page MenuHomePhabricator

Development Lifecycle Steps
Updated 646 Days AgoPublic

Version 1 of 3: You are viewing an older version of this document, as it appeared on Jul 4 2019, 2:23 PM.

This page details how to contributing code to Arm NN, it assumes you already have a working version of Arm NN.
For instructions to install Arm NN refer to Getting Started with Arm NN.


Contributing to Arm NN

Contributions are welcome to Arm NN. The projects are licensed under the MIT license and all accepted contributions must have the same license.

To contribute to a machine learning platform repository, please put a change request on review.mlplatform.org. (Please do not make pull requests on the GitHub repositories.)

Developer Certificate of Origin (DCO)

Before the machine learning platform project can accept your contribution, you must certify its origin and give us your permission. To manage this process we use the Developer Certificate of Origin (DCO) V1.1 (https://developercertificate.org/)

To indicate that you agree to the terms of the DCO, you “sign off” your contribution by adding a line with your name and e-mail address to every git commit message:

Signed-off-by: John Doe john.doe@example.org

You must use your real name. No pseudonyms or anonymous contributions are accepted.


Creating a change

Before creating you change make sure you have the latest version of Arm NN

$ git pull

Create a local branch for you changes

$ git checkout -b "branchname"

Stage your changes once they have been made

$ git add "filename"

Run make in your build directory to make sure your code compiles

$ make

Committing changes

Set your sign off username and email

$ git config user.name "YourName"

$ git config user.email "your.name@site.com"

Commit your changes

$ git commit -s

Commit messages

Commit messages must follow a specific format in order to ensure the log message is easy to read. There are a few important parts to each commit message.

  • The first line of the commit message must contain a high-level summary of the commit.
  • The summary line must be followed by a blank line - this clearly separates the summary from the description.
  • Subsequent lines should contain further details of the commit - expanding on the summary line at the top of the commit.
  • The end of the commit message must include a Change-Id trailer.
  • The end of the commit message must include a Signed-off-by trailer - this is added with the -s flag ---

An example commit message

MIMIR-1234: Code tidy-up following Alpha review (no functional changes)
  
  * Removed hanging whitespace.
  * Replaced tabs with spaces.
  * Added comments
 
Signed-off-by: YourName <your.name@site.com>
Change-Id: If4f3092c7f30cd9bc53c8a5310bb890ec31f70bc

Pushing a commit

To push a change for review

$ git push origin HEAD:refs/for/master

Before a change is merged into master, it must:

  1. Be reviewed by at least one (preferably two) developers at Arm who will inspect the changes and provide feedback.
  2. Compile and pass appropriate testing on Arm's CI (Continuous Integration) system.

Review ratings are given as follows:

Code Review

  • +2: The change is definitely OK and can be merged (normally only set by the second reviewer after the first has given +1).
  • +1: The change looks OK, but could do with another reviewer taking a look.
  • -1: Some minor points need to be fixed - I would prefer you do not submit yet.
  • -2: There are serious issues with this change (broken feature, deviation from spec, etc.) - do not commit.

CI Verified

  • +1: Appropriate testing has been done to ensure functionality is correct.
  • -1: Testing has failed.

Amending a commit

You may need to make changes to your commit, due to either feedback from the code review, the CI build/tests failing, or needing to change the commit message

To do so make your stage any additional changes you've made

$ git add "filename"

Amend your commit

$ git commit --amend

Then re-push for review

$ git push origin HEAD:refs/for/master

Rebasing

During code review you may need to rebase your changes before merging with master to do so click the Rebase button.
If you are unlucky or you might get a merge conflict, in which case you will be to rebase and resolve the conflict locally, then re-push.

Merge the changes

Once the CI and the reviewers are happy

Deleting branches

Once your changes have been integrated to master delete your branch

$ git branch -D <branch_name>
Last Author
FinnWilliamsArm
Last Edited
Jul 4 2019, 2:23 PM

Event Timeline

FinnWilliamsArm edited the content of this document. (Show Details)
FinnWilliamsArm edited the content of this document. (Show Details)Jul 4 2019, 2:37 PM
FinnWilliamsArm edited the content of this document. (Show Details)Jul 4 2019, 4:22 PM
FinnWilliamsArm published a new version of this document.Jul 5 2019, 9:05 AM
MatthewARM changed the visibility from "All Users" to "Public (No Login Required)".Jun 18 2020, 9:00 AM