When creating an Envoy pull request (PR) the text box will automatically be filled in with the basic fields from the pull request template. The following is a more detailed explanation of what should go in each field.
The title of the PR should brief (one line) noting the subsystem or the aspect this PR applies to and explaining the overall change. Both the component and the explanation must be lower case. For example:
- ci: update build image to 44d539cb
- docs: fix indent, buffer: add copyOut() method
- router:add x-envoy-overloaded header
- tls: add support for specifying TLS session ticket keys
The commit message field should include an explanation of what this PR does. This will be used as the final commit message that maintainers will use to populate the commit message when merging. If this PR causes a change in behavior it should document the behavior before and after. If fixing a bug, please describe what the original issue is and how the change resolves it. If it is configuration controlled, it should note how the feature is enabled etc...
The additional description field should include information of what this PR does that may be out of scope for a commit message. This could include additional information or context useful to reviewers.
Risk Level is one of: Low | Medium | High
Low: Small bug fix or small optional feature.
Medium: New features that are not enabled(for example: new filter). Small-medium features added to existing components(for example: modification to an existing filter).
High: Complicated changes such as flow control, rewrites of critical components, etc.
Note: The above is only a rough guide for choosing a level, please ask if you have any concerns about the risk of the PR.
The testing section should include an explanation of what testing was done, for example: unit test, integration, manual testing, etc.
Note: It isn’t expected to do all forms of testing, please use your best judgement or ask for guidance if you are unsure. A good rule of thumb is the riskier the change, the more comprehensive the testing should be.
If there are documentation changes, please include a brief description of what they are. Docs changes may be in docs/root and/or inline with the API protos. Please write in N/A if there were no documentation changes.
Any PRs with structural changes to the dataplane should also update the Life of a Request documentation as appropriate.
If this change is user impacting OR extension developer impacting (filter API, etc.) you must add a release note to the version history for the current version. Please include any relevant links. Each release note should be prefixed with the relevant subsystem in alphabetical order (see existing examples as a guide) and include links to relevant parts of the documentation. Thank you! Please write in N/A if there are no release notes.
If this change involves any platform specific features (e.g. utilizing OS-specific socket options)
or only implements new features for a limited set of platforms (e.g. Linux amd64 only), please
include an explanation that addresses the reasoning behind this. Please also open a new tracking
issue for each platform this change is not implemented on (and link them in the PR) to enable
maintainers and contributors to triage. Reviewers will look for the change to avoid
#ifdef <OSNAME> and rather prefer feature guards to not enable the change on a given platform
using the build system.
If this PR has a user-visible behavioral change, or otherwise falls under the guidelines for runtime guarding in the contributing doc it should have a runtime guard, which should be documented both in the release notes and here in the PR description.
For new feature additions guarded by configs, no-op refactors, docs changes etc. this field can be disregarded and/or removed.
If this PR fixes an outstanding issue, please add a line of the form:
Fixes #Issue
This will result in the linked issue being automatically closed when the PR is merged. If you want to associate an issue with a PR without closing the issue, you may instead just tag the PR with the issue:
#Issue
If this PR deprecates existing Envoy APIs or code, it should include an update to the deprecated section of the version history and a one line note in the PR description.
If you mark existing APIs or code as deprecated, when the next release is cut, the deprecation script will create and assign an issue to you for cleaning up the deprecated code path.