The Mbed TLS core team prioritise PRs to help us spend our review capacity on the items that best help the project.
When PRs are first triaged, a label is applied to help reviewers determine what to work on (and what not to work on). The different classifications are described below.
Please note that if your PR falls into the lower priority categories, we are happy to increase its priority if needed. This might happen through:
Commenting on the PR to explain why there is an important use-case for it
Other users commenting to show wider demand for the PR
Attending the regular Tech Forum call to discuss the PR
Advocating for the PR on the project mailing list
Find others to review your PR
Classifications are done through labels, e.g.: priority-high.
Please note that these are the priorities used by the core team. External contributors are welcome to review PRs according to their own priorities, and such review activity will help highlight PRs which should get attention from the core team.
Same criteria as priority-high, below, but needed for the Mbed TLS team’s most important commitments.
This classification is often used for vulnerability fixes with a public disclosure date.
This classification is used for PRs which have a target date for merging - typically one of:
Security (or other high-priority) bug fixes needed in the next release
Items that the Mbed TLS team have planned for delivery in the current quarter
These PRs should receive review promptly.
This is for PRs which advance the core team’s aims for Mbed TLS, but are not needed to meet delivery in the current quarter. These PRs will receive review on a best-effort basis, but assistance from the community would be helpful.
These would typically address one of the following areas:
Non-urgent and lower-priority security improvements
Non-urgent bug fixes
Provide a reference implementation for PSA Crypto
Driver interface for secure elements & crypto processors
Support latest TLS versions and features - especially client features important for embedded devices
Improvements to code-size, memory footprint and performance on embedded devices
This is for PRs which are potentially useful or nice to have, but are unlikely to receive review soon. This might include PRs in the following areas:
New ciphers for which there is low demand
Minor performance enhancements
Enhancements that don’t suit embedded applications
Code (especially assembly) for platforms where the team has little experience for review or maintenance, or limited ability to test
Note: we currently have the capability to maintain & test aarch32, aarch64, x86 and x86-64 on Ubuntu, FreeBSD and Windows
Minor quality/test improvements, e.g. clean-up of test infrastructure or build scripts
Items where the team might not be able to afford the maintenance cost
After at least one year, some items in this category may be closed if a clear need does not emerge with time. This is more likely to happen for larger and more complex PRs.
This is an additional label used for larger PRs (typically priority-medium) which require significant team bandwidth to review. These items will not be reviewed immediately, but they will be scheduled in the project roadmap with time allocated for review.