blob: bfd6cb3d7026aab800c5d60362d667a4f0958261 [file] [log] [blame] [view]
Ron Eldorb5e6a772017-08-16 11:23:31 +03001We gratefully accept bug reports and contributions from the community. There are some requirements we need to fulfill in order to be able to integrate contributions:
2
Ron Eldor7f888982017-08-16 16:05:52 +03003 - As with any open source project, contributions will be reviewed by the project team and community and may need some modifications to be accepted.
4 - The contribution should not break API or ABI, unless there is a real justification for that. If there is an API change, the contribution, if accepted, will be merged only when there will be a major release.
5
6### Contributor License Agreement ( CLA )
Ron Eldorb5e6a772017-08-16 11:23:31 +03007- All contributions, whether large or small require a Contributor's License Agreement (CLA) to be accepted. This is because source code can possibly fall under copyright law and we need your consent to share in the ownership of the copyright.
Ron Eldor7f888982017-08-16 16:05:52 +03008- To accept the Contributor’s License Agreement (CLA), individual contributors can do this by creating an mbed account and [accepting the online agreement here with a click through](https://developer.mbed.org/contributor_agreement/). Alternatively, for contributions from corporations, or those that do not wish to create an mbed account, a slightly different agreement can be found [here](https://www.mbed.com/en/about-mbed/contributor-license-agreements/). This agreement should be signed and returned to ARM as described in the instructions given.
9
10### Coding Standards
11- We would ask that contributions conform to [our coding standards](https://tls.mbed.org/kb/development/mbedtls-coding-standards), and that contributions are fully tested before submission.
12- The code should be written in a clean and readable style.
13- The code should be written in a portable generic way, that will benefit the whole community, and not only your own needs.
14- The code should be secure, and will be reviewed in a security point of view as well.
Ron Eldorb5e6a772017-08-16 11:23:31 +030015
16### Making a Contribution
17
181. [Check for open issues](https://github.com/ARMmbed/mbedtls/issues) or [start a discussion](https://tls.mbed.org/discussions) around a feature idea or a bug.
192. Fork the [mbed TLS repository on GitHub](https://github.com/ARMmbed/mbedtls) to start making your changes. As a general rule, you should use the "development" branch as a basis.
203. Write a test which shows that the bug was fixed or that the feature works as expected.
Ron Eldor7f888982017-08-16 16:05:52 +0300214. Send a pull request (PR) and work with us until it gets merged and published. Contributions may need some modifications, so a few rounds of review and fixing may be necessary. We will include your name in the ChangeLog :)
Ron Eldorb5e6a772017-08-16 11:23:31 +030022
23### Backports
24
Ron Eldor7f888982017-08-16 16:05:52 +030025mbed TLS maintains some legacy branches, which are released as LTS versions. mbed TLS should follow backwards compatibility rules, to fit with existing users. As such, backporting to these branches should be handled according to the following rules:
Ron Eldorb5e6a772017-08-16 11:23:31 +030026
Ron Eldor7f888982017-08-16 16:05:52 +0300271. If the contribution is a new feature or enhancement, no backporting is needed.
282. Bug fixes should be backported to the legacy branches containing these bugs.
293. Changes in the API do not require backporting. If a bug fix introduced a new API, such as new error codes, the bug fix should be implemented differently in the legacy branch.
Ron Eldorb5e6a772017-08-16 11:23:31 +030030
31It would be highly appreciated if a contribution would be backported to a legacy branch as well.
32At the moment, the legacy branches are:
33
341. [mbedtls-1.3](https://github.com/ARMmbed/mbedtls/tree/mbedtls-1.3)
352. [mbedtls-2.1](https://github.com/ARMmbed/mbedtls/tree/mbedtls-2.1)
363. [development](https://github.com/ARMmbed/mbedtls/tree/development)
37
38### Tests
39
Ron Eldor7f888982017-08-16 16:05:52 +030040As mentioned, tests that show the correctness of the feature or bug fix should be added to the Pull Request, if no such tests exist.
Ron Eldorb5e6a772017-08-16 11:23:31 +030041mbed TLS includes an elaborate test suite in `tests/` that initially requires Perl to generate the tests files (e.g. `test_suite_mpi.c`). These files are generated from a `function file` (e.g. `suites/test_suite_mpi.function`) and a `data file` (e.g. `suites/test_suite_mpi.data`). The function file contains the test functions. The data file contains the test cases, specified as parameters that will be passed to the test function.
42
Ron Eldor7f888982017-08-16 16:05:52 +030043Sample applications, if needed, should be modified as well.
44
Ron Eldorb5e6a772017-08-16 11:23:31 +030045### Continuous Integration Tests
46
Ron Eldor7f888982017-08-16 16:05:52 +030047Once a PR has been made, the Continuous Integration (CI) tests are triggered and run. You should follow the result of the CI tests, and fix failures.
48
49### Documentation
50
51mbed TLS should be well documented. If documentation is needed, speak out!
52
531. All interfaces should be documented through Doxygen. New APIs should introduce Doxygen documentation.
542. Complex parts in the code should include comments.
553. If needed, a Readme file is advised
564. If a KB article should be added, write this as a comment in the PR description.
575. A Changelog entry should be added for this contribution.
Ron Eldorb5e6a772017-08-16 11:23:31 +030058
59
60