We'd love to accept your patches and contributions to this project. There are just a few small guidelines you need to follow.
Contributions to this project must be accompanied by a Contributor License Agreement (CLA). You (or your employer) retain the copyright to your contribution; this simply gives us permission to use and redistribute your contributions as part of the project. Head over to https://cla.developers.google.com/ to see your current agreements on file or to sign a new one.
You generally only need to submit a CLA once, so if you‘ve already submitted one (even if it was for a different project), you probably don’t need to do it again.
This project follows Google's Open Source Community Guidelines.
We provide some general guidelines with the goal of enabling community contributions while still maintaining code health, maintainability, and consistency in style.
Please note that while these guidelines may seem onerous to some developers, they are derived from Google's software engineering best practices.
Before we describe project-specific guidelines, we recommend that external contributors read these tips from the Google Testing Blog:
We also recommend that contributors take a look at the Tensorflow Contributing Guidelines.
We strongly recommend that contributors:
Initiate a conversation with the TFLM team via a TF Lite Micro Github issue as early as possible.
This enables us to give guidance on how to proceed, prevent duplicated effort and also point to alternatives as well as context if we are not able to accept a particular contribution at a given time.
Ideally, you should make an issue before starting to work on a pull request and provide context on both what you want to contribute and why.
Once step 1. is complete and it is determined that a PR from an external contributor is the way to go, please follow these guidelines from Google's Engineering Practices documentation:
Write Good Pull Request Descriptions
We require that all PR descriptions link to the github issue created in step 1.
While github offers flexibility in linking commits and issues, we require that the PR description have a separate line with either Fixes #nn (if the PR fixes the issue) or Issue #nn if the PR addresses some aspect of an issue without fixing it.
We will be adding internal checks that automate this requirement by matching the PR description to the regexp: (Fixes|Issue) #
Unit tests are critical to a healthy codebase. PRs without tests should be the exception rather than the norm. And contributions to improve, simplify, or make the unit tests more exhaustive are welcome! Please refer to this guideline on how test code and writing small PRs should be reconciled.
We provide some additional guidelines for different categories of contributions.
Pull requests that fix bugs are always welcome and often uncontroversial, unless there is a conflict between different requirements from the platform, or if fixing a bug needs a bigger architectural change.
Pull requests that port reference kernels from TF Lite Mobile to TF Lite Micro are welcome once we have enough context from the contributor on why the additional kernel is needed.
Please create a TF Lite Micro Github issue before starting on any such PRs with as much context as possible, such as:
In the interest of having small pull requests, limit each pull request to porting a single kernel (and the corresponding test).
TODO(b/165627437): Create and link to a guide to porting reference ops.
In order to have the TFLM codebase be a central repository of optimized kernel implementations, we would like to make some improvements to the current infrastructure to enable adding and maintaining optimized kernel implementations in a scalable way.
Until that work is complete, we are requesting a pause on contributions that add new optimized kernel implementations. We plan to make these improvements by October 2020 and will provide additional guidelines at that time.
If you would like to have an exception to this pause, with the understanding that your optimized kernels will break as we improve the underlying framework, then please send an email to the SIG Micro email group to figure out a middle ground.
Every optimized kernel directory must have a README.md with the github IDs of the maintainers and any other relevant documentation. PRs that add maintainers to the existing optimized kernels are always welcome.
As discussed in the SIG-micro Aug 12, 2020 meeting, we are currently pausing accepting pull requests that add new targets, platforms, IDE integration or examples while we revisit some of the infrastructure to enable us to make this process easier and more scalable.
In the meantime, snapshotting and/or forking the tensorflow repo could be a viable way to prototype platform support.
Having said that, we still invite TF Lite Micro Github issues on this topic as we would like to enable such integration in the future.
As discussed in the SIG-micro Aug 12, 2020 meeting, we are currently pausing accepting pull requests that add new features while we revisit some of the infrastructure to enable us to make this process easier and more scalable.
Having said that, we still invite feature requests via TF Lite Micro Github issues to determine if the requested feature aligns with the TFLM roadmap.
Below are some tips that might be useful and improve the development experience.
Add the Refined GitHub plugin to make the github experience even better.
Code search the TfLite Micro codebase on Sourcegraph. And optionally install the plugin that enables GitHub integration.
Install bazel and buildifier.
Install the latest clang and clang-format. For example, here is the what we do for the TFLM continuous integration Docker container.
Get a copy of cpplint
Add a git hook to check for code style etc. prior to creating a pull request:
cp tensorflow/lite/micro/tools/dev_setup/pre-push.tflm .git/hooks/pre-push
Run in-place clang-format on all the files that are modified in your git tree with
clang-format -i -style=google `git ls-files -m | grep "\.cc"` clang-format -i -style=google `git ls-files -m | grep "\.h"`
Make sure your code is lint-free.
cpplint.py `git ls-files -m`
Run all the tests for x86, and any other platform that you are modifying.
tensorflow/lite/micro/tools/ci_build/test_x86.sh
Please check the READMEs in the optimized kernel directories for specific instructions.
Sometimes, bugs are caught by the sanitizers that can go unnoticed via the Makefile. To run a test with the different sanitizers, use the following commands (replace micro_interpreter_test with the target that you want to test:
CC=clang bazel run --config=asan tensorflow/lite/micro:micro_interpreter_test CC=clang bazel run --config=msan tensorflow/lite/micro:micro_interpreter_test CC=clang bazel run --config=ubsan tensorflow/lite/micro:micro_interpreter_test
Do not change the git version history.
Always merge upstream/master (do not rebase) and no force-pushes please.
Having an extra merge commit it ok as the github review tool handles that gracefully.
Assuming that you forked tensorflow and added a remote called upstream with:
git remote add upstream https://github.com/tensorflow/tflite-micro.git
Fetch the latest changes from upstream and merge into your local branch.
git fetch upstream git merge upstream/main
In case of a merge conflict, resolve via:
git mergetool # Use your favorite diff tools (e.g. meld) to resolve the conflicts. git add <files that were manually resolved> git commit
If a force push seems to be the only path forward, please stop and let your PR reviewer know before force pushing. We will attempt to do the merge for you. This will also help us better understand in what conditions a force-push may be unavoidable.
GIthub CLI can be useful to quickly checkout a PR to test locally.
gh pr checkout <PR number>
Google engineers on the Tensorflow team will have the permissions to push edits to most PRs. This can be useful to make some small fixes as a result of errors due to internal checks that are not easily reproducible via github.
One example of this is this comment.
And a sketch of the steps:
git remote add <remote_name> git@github.com:<PR author>/tensorflow.git git fetch <remote_name> git checkout -b <local-branch-name> <remote_name>/<PR branch name> # make changes and commit to local branch # push changes to remove branch git push <remote_name> <PR branch name> # remove the temp remote to clean up your git environment. git remote rm <remote_name>
Most PRs for TensorFlow Lite Micro will be C++ only. Adding some notes on Python that can be expanded and improved as necessary.
TensorFlow guide for Python development
yapf should be used for formatting.
yapf log_parser.py -i --style='{based_on_style: pep8, indent_width: 2}'
docker build -t tflm-test -f ci/Dockerfile.micro . docker run --rm tflm-test