40 lines
1.4 KiB
Markdown
40 lines
1.4 KiB
Markdown
|
Notes:
|
||
|
|
* Pull requests cannot be accepted until:
|
||
|
|
- The submitter has [accepted the online agreement here with a click through](https://developer.mbed.org/contributor_agreement/)
|
||
|
|
or for companies 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/)
|
||
|
|
- The PR follows the [mbed TLS coding standards](https://tls.mbed.org/kb/development/mbedtls-coding-standards)
|
||
|
|
* This is just a template, so feel free to use/remove the unnecessary things
|
||
|
|
## Description
|
||
|
|
A few sentences describing the overall goals of the pull request's commits.
|
||
|
|
|
||
|
|
|
||
|
|
## Status
|
||
|
|
**READY/IN DEVELOPMENT/HOLD**
|
||
|
|
|
||
|
|
## Requires Backporting
|
||
|
|
When there is a bug fix, it should be backported to all maintained and supported branches.
|
||
|
|
Changes do not have to be backported if:
|
||
|
|
- This PR is a new feature\enhancement
|
||
|
|
- This PR contains changes in the API. If this is true, and there is a need for the fix to be backported, the fix should be handled differently in the legacy branch
|
||
|
|
|
||
|
|
Yes | NO
|
||
|
|
Which branch?
|
||
|
|
|
||
|
|
## Migrations
|
||
|
|
If there is any API change, what's the incentive and logic for it.
|
||
|
|
|
||
|
|
YES | NO
|
||
|
|
|
||
|
|
## Additional comments
|
||
|
|
Any additional information that could be of interest
|
||
|
|
|
||
|
|
## Todos
|
||
|
|
- [ ] Tests
|
||
|
|
- [ ] Documentation
|
||
|
|
- [ ] Changelog updated
|
||
|
|
- [ ] Backported
|
||
|
|
|
||
|
|
|
||
|
|
## Steps to test or reproduce
|
||
|
|
Outline the steps to test or reproduce the PR here.
|