1<!-- 2emi-automated TOC generation with instructions from 3https://github.com/ekalinin/github-markdown-toc#auto-insert-and-update-toc 4--> 5<!--ts--> 6 * [How to Contribute](#how-to-contribute) 7 * [Contributor License Agreement](#contributor-license-agreement) 8 * [Community Guidelines](#community-guidelines) 9 * [Code Contribution Guidelines](#code-contribution-guidelines) 10 * [General Pull Request Guidelines](#general-pull-request-guidelines) 11 * [Guidelines for Specific Contribution Categories](#guidelines-for-specific-contribution-categories) 12 * [Bug Fixes](#bug-fixes) 13 * [Reference Kernel Implementations](#reference-kernel-implementations) 14 * [Optimized Kernel Implementations](#optimized-kernel-implementations) 15 * [New Target / Platform / IDE / Examples](#new-target--platform--ide--examples) 16 * [New Features](#new-features) 17 * [Development Workflow Notes](#development-workflow-notes) 18 * [Initial Setup](#initial-setup) 19 * [Before submitting your PR](#before-submitting-your-pr) 20 * [During the PR review](#during-the-pr-review) 21 * [Reviewer notes](#reviewer-notes) 22 * [Python notes](#python-notes) 23 * [Continuous Integration System](#continuous-integration-system) 24 25<!-- Added by: advaitjain, at: Fri 09 Apr 2021 12:51:55 PM PDT --> 26 27<!--te--> 28 29# How to Contribute 30 31We'd love to accept your patches and contributions to this project. There are 32just a few small guidelines you need to follow. 33 34## Contributor License Agreement 35 36Contributions to this project must be accompanied by a Contributor License 37Agreement (CLA). You (or your employer) retain the copyright to your 38contribution; this simply gives us permission to use and redistribute your 39contributions as part of the project. Head over to 40<https://cla.developers.google.com/> to see your current agreements on file or 41to sign a new one. 42 43You generally only need to submit a CLA once, so if you've already submitted one 44(even if it was for a different project), you probably don't need to do it 45again. 46 47## Community Guidelines 48 49This project follows 50[Google's Open Source Community Guidelines](https://opensource.google/conduct/). 51 52# Code Contribution Guidelines 53 54We provide some general guidelines with the goal of enabling community 55contributions while still maintaining code health, maintainability, and 56consistency in style. 57 58Please note that while these guidelines may seem onerous to some developers, 59they are derived from Google's software engineering best practices. 60 61Before we describe project-specific guidelines, we recommend that external 62contributors read these tips from the Google Testing Blog: 63 64* [Code Health: Providing Context with Commit Messages and Bug Reports](https://testing.googleblog.com/2017/09/code-health-providing-context-with.html) 65* [Code Health: Understanding Code In Review](https://testing.googleblog.com/2018/05/code-health-understanding-code-in-review.html) 66* [Code Health: Too Many Comments on Your Code Reviews?](https://testing.googleblog.com/2017/06/code-health-too-many-comments-on-your.html) 67* [Code Health: To Comment or Not to Comment?](https://testing.googleblog.com/2017/07/code-health-to-comment-or-not-to-comment.html) 68 69We also recommend that contributors take a look at the 70[Tensorflow Contributing Guidelines](https://github.com/tensorflow/tensorflow/blob/master/CONTRIBUTING.md). 71 72## General Pull Request Guidelines 73 74We strongly recommend that contributors: 75 761. Initiate a conversation with the TFLM team via a 77 [TF Lite Micro Github issue](https://github.com/tensorflow/tensorflow/issues/new?labels=comp%3Amicro&template=70-tflite-micro-issue.md) 78 as early as possible. 79 80 * This enables us to give guidance on how to proceed, prevent duplicated 81 effort and also point to alternatives as well as context if we are not 82 able to accept a particular contribution at a given time. 83 84 * Ideally, you should make an issue ***before*** starting to work on a 85 pull request and provide context on both what you want to contribute and 86 why. 87 881. Once step 1. is complete and it is determined that a PR from an external 89 contributor is the way to go, please follow these guidelines from 90 [Google's Engineering Practices documentation](https://google.github.io/eng-practices/): 91 92 * [Send Small Pull Requests](https://google.github.io/eng-practices/review/developer/small-cls.html) 93 94 * If a pull request is doing more than one thing, the reviewer will 95 request that it be broken up into two or more PRs. 96 97 * [Write Good Pull Request Descriptions](https://google.github.io/eng-practices/review/developer/cl-descriptions.html) 98 99 * We require that all PR descriptions link to the github issue created 100 in step 1. 101 102 * While github offers flexibility in linking 103 [commits and issues](https://github.blog/2011-04-09-issues-2-0-the-next-generation/#commits-issues), 104 we require that the PR description have a separate line with 105 `BUG=#nn`. 106 107 * We will be adding internal checks that automate this requirement by 108 matching the PR description to the regexp: `(Fixes|Issue) #` 109 1101. Unit tests are critical to a healthy codebase. PRs without tests should be 111 the exception rather than the norm. And contributions to improve, simplify, 112 or make the unit tests more exhaustive are welcome! Please refer to 113 [this guideline](https://google.github.io/eng-practices/review/developer/small-cls.html#test_code) 114 on how test code and writing small PRs should be reconciled. 115 116## Guidelines for Specific Contribution Categories 117 118We provide some additional guidelines for different categories of contributions. 119 120### Bug Fixes 121 122Pull requests that fix bugs are always welcome and often uncontroversial, unless 123there is a conflict between different requirements from the platform, or if 124fixing a bug needs a bigger architectural change. 125 1261. Create a 127 [TF Lite Micro Github issue](https://github.com/tensorflow/tensorflow/issues/new?labels=comp%3Amicro&template=70-tflite-micro-issue.md) 128 to determine the scope of the bug fix. 1291. Send a PR (if that is determined to be the best path forward). 1301. Bugfix PRs should be accompanied by a test case that fails prior to the fix 131 and passes with the fix. This validates that the fix works as expected, and 132 helps prevent future regressions. 133 134### Reference Kernel Implementations 135 136Pull requests that port reference kernels from TF Lite Mobile to TF Lite Micro 137are welcome once we have enough context from the contributor on why the 138additional kernel is needed. 139 1401. Please create a 141 [TF Lite Micro Github issue](https://github.com/tensorflow/tensorflow/issues/new?labels=comp%3Amicro&template=70-tflite-micro-issue.md) 142 before starting on any such PRs with as much context as possible, such as: 143 144 * What is the model architecture? 145 * What is the application that you are targetting? 146 * What embedded target(s) are you planning to run on? 147 * Motivate your use-case and the need for adding support for this 148 additional OP. 149 1501. In the interest of having 151 [small pull requests](https://google.github.io/eng-practices/review/developer/small-cls.html), 152 limit each pull request to porting a single kernel (and the corresponding 153 test). 154 1551. TODO(b/165627437): Create and link to a guide to porting reference ops. 156 157### Optimized Kernel Implementations 158 159In order to have the TFLM codebase be a central repository of optimized kernel 160implementations, we would like to make some improvements to the current 161infrastructure to enable adding and maintaining optimized kernel implementations 162in a scalable way. 163 164Until that work is complete, we are requesting a ***pause*** on contributions that 165add new optimized kernel implementations. We plan to make these improvements by 166October 2020 and will provide additional guidelines at that time. 167 168* If you would like to have an exception to this pause, with the understanding 169 that your optimized kernels will break as we improve the underlying 170 framework, then please send an email to the [SIG Micro email 171 group](https://groups.google.com/a/tensorflow.org/g/micro) to figure out 172 a middle ground. 173 174* Every optimized kernel directory must have a README.md with the github IDs 175 of the maintainers and any other relevant documentation. PRs that add 176 maintainers to the existing optimized kernels are always welcome. 177 178### New Target / Platform / IDE / Examples 179 180As discussed in the 181[SIG-micro Aug 12, 2020 meeting](http://doc/1YHq9rmhrOUdcZnrEnVCWvd87s2wQbq4z17HbeRl-DBc), 182we are currently ***pausing*** accepting pull requests that add new targets, 183platforms, IDE integration or examples while we revisit some of the 184infrastructure to enable us to make this process easier and more scalable. 185 186In the meantime, snapshotting and/or forking the tensorflow repo could be a 187viable way to prototype platform support. 188 189Having said that, we still invite 190[TF Lite Micro Github issues](https://github.com/tensorflow/tensorflow/issues/new?labels=comp%3Amicro&template=70-tflite-micro-issue.md) 191on this topic as we would like to enable such integration in the future. 192 193### New Features 194 195As discussed in the 196[SIG-micro Aug 12, 2020 meeting](http://doc/1YHq9rmhrOUdcZnrEnVCWvd87s2wQbq4z17HbeRl-DBc), 197we are currently ***pausing*** accepting pull requests that add new features while 198we revisit some of the infrastructure to enable us to make this process easier 199and more scalable. 200 201Having said that, we still invite feature requests via 202[TF Lite Micro Github issues](https://github.com/tensorflow/tensorflow/issues/new?labels=comp%3Amicro&template=70-tflite-micro-issue.md) 203to determine if the requested feature aligns with the TFLM roadmap. 204 205# Development Workflow Notes 206 207## Initial Setup 208 209Below are some tips that might be useful and improve the development experience. 210 211* Add the [Refined GitHub](https://github.com/sindresorhus/refined-github) 212 plugin to make the github experience even better. 213 214* Code search the [TfLite Micro codebase](https://sourcegraph.com/github.com/tensorflow/tflite-micro@main) 215 on Sourcegraph. And optionally install the [plugin that enables GitHub integration](https://docs.sourcegraph.com/integration/github#github-integration-with-sourcegraph). 216 217* Install [bazel](ci/install_bazel.sh) and [buildifier](ci/install_buildifier.sh). 218 219* Install the latest clang and clang-format. For example, [here](ci/Dockerfile.micro) 220 is the what we do for the TFLM continuous integration Docker container. 221 222* Get a copy of [cpplint](https://github.com/google/styleguide/tree/gh-pages/cpplint) 223 224* [yapf](https://github.com/google/yapf/) should be used for formatting Python 225 code. For example: 226 227 ``` 228 pip3 install yapf 229 yapf log_parser.py -i --style='{based_on_style: pep8, indent_width: 2}' 230 ``` 231 232* Add a git hook to check for code style etc. prior to creating a pull request: 233 ``` 234 cp tensorflow/lite/micro/tools/dev_setup/pre-push.tflm .git/hooks/pre-push 235 ``` 236 237## Before submitting your PR 238 2391. Run in-place clang-format on all the files that are modified in your git 240 tree with 241 242 ``` 243 clang-format -i -style=google `git ls-files -m | grep "\.cc"` 244 clang-format -i -style=google `git ls-files -m | grep "\.h"` 245 ``` 246 2471. Make sure your code is lint-free. 248 249 ``` 250 cpplint.py `git ls-files -m` 251 ``` 252 2531. Run all the tests for x86, and any other platform that you are modifying. 254 255 ``` 256 tensorflow/lite/micro/tools/ci_build/test_x86.sh 257 ``` 258 259 Please check the READMEs in the optimized kernel directories for specific 260 instructions. 261 2621. Sometimes, bugs are caught by the sanitizers that can go unnoticed 263 via the Makefile. To run a test with the different sanitizers, use the 264 following commands (replace `micro_interpreter_test` with the target that you 265 want to test: 266 267 ``` 268 CC=clang bazel run --config=asan tensorflow/lite/micro:micro_interpreter_test 269 CC=clang bazel run --config=msan tensorflow/lite/micro:micro_interpreter_test 270 CC=clang bazel run --config=ubsan tensorflow/lite/micro:micro_interpreter_test 271 ``` 272 273## During the PR review 274 2751. Do not change the git version history. 276 277 * Always merge upstream/main (***do not rebase***) and no force-pushes 278 please. 279 280 * Having an extra merge commit it ok as the github review tool handles 281 that gracefully. 282 283 Assuming that you forked tensorflow and added a remote called upstream with: 284 285 ``` 286 git remote add upstream https://github.com/tensorflow/tflite-micro.git 287 ``` 288 289 Fetch the latest changes from upstream and merge into your local branch. 290 291 ``` 292 git fetch upstream 293 git merge upstream/main 294 ``` 295 296 In case of a merge conflict, resolve via: 297 298 ``` 299 git mergetool 300 301 # Use your favorite diff tools (e.g. meld) to resolve the conflicts. 302 303 git add <files that were manually resolved> 304 305 git commit 306 ``` 307 3081. If a force push seems to be the only path forward, please stop and let your 309 PR reviewer know ***before*** force pushing. We will attempt to do the merge 310 for you. This will also help us better understand in what conditions a 311 force-push may be unavoidable. 312 313## Reviewer notes 314 315* [GIthub CLI](https://cli.github.com) can be useful to quickly checkout a PR 316 to test locally. 317 318 `gh pr checkout <PR number>` 319 320* Google engineers on the Tensorflow team will have the permissions to push 321 edits to most PRs. This can be useful to make some small fixes as a result 322 of errors due to internal checks that are not easily reproducible via 323 github. 324 325 One example of this is 326 [this comment](https://github.com/tensorflow/tensorflow/pull/38634#issuecomment-683190474). 327 328 And a sketch of the steps: 329 330 ``` 331 git remote add <remote_name> git@github.com:<PR author>/tensorflow.git 332 git fetch <remote_name> 333 334 git checkout -b <local-branch-name> <remote_name>/<PR branch name> 335 336 # make changes and commit to local branch 337 338 # push changes to remove branch 339 340 git push <remote_name> <PR branch name> 341 342 # remove the temp remote to clean up your git environment. 343 344 git remote rm <remote_name> 345 ``` 346 347## Python notes 348 349* [TensorFlow guide](https://www.tensorflow.org/community/contribute/code_style#python_style) 350 for Python development 351 352# Continuous Integration System 353 * Some [additional documentation](docs/continuous_integration.md) on the TFLM CI. 354