All extensions contained in the main Envoy repository will be held to the same quality bar as the core Envoy code. This includes coding style, code reviews, test coverage, etc. In the future we may consider creating a sandbox repository for extensions that are not compiled/tested by default and held to a lower quality standard, but that is out of scope currently.
The following procedure will be used when proposing new extensions for inclusion in the repository:
A GitHub issue should be opened describing the proposed extension as with any major feature proposal.
All extensions must be sponsored by an existing maintainer. Sponsorship means that the maintainer will shepherd the extension through design/code reviews. Maintainers can self-sponsor extensions if they are going to write them, shepherd them, and maintain them.
Sponsorship serves two purposes:
If sponsorship cannot be found from an existing maintainer, an organization can consider doing the work to become a maintainer in order to be able to self-sponsor extensions.
Each extension must have two reviewers proposed for reviewing PRs to the extension. Neither of the reviewers must be a senior maintainer. Existing maintainers (including the sponsor) and other contributors can count towards this number. The initial reviewers will be codified in the CODEOWNERS file for long term maintenance. These reviewers can be swapped out as needed.
Any extension added via this process becomes a full part of the repository. This means that any API breaking changes in the core code will be automatically fixed as part of the normal PR process by other contributors.
As stated in the previous section, once an extension becomes part of the repository it will be maintained by the collective set of Envoy contributors as needed.
However, if an extension has known issues that are not being rectified by the original sponsor and reviewers or new contributors that are willing to step into the role of extension owner, a vote of the maintainers can be called to remove the extension from the repository.
Extension PRs must not modify core Envoy code. In the event that an extension requires changes to core Envoy code, those changes should be submitted as a separate PR and will undergo the normal code review process, as documented in the contributor's guide.
Extension PRs must be approved by at least one sponsoring maintainer and an extension reviewer. These may be a single individual, but it is always preferred to have multiple reviewers when feasible.
In the event that the Extension PR author is a sponsoring maintainer and no other sponsoring maintainer is available, another maintainer may be enlisted to perform a minimal review for style and common C++ anti-patterns. The Extension PR must still be approved by a non-maintainer reviewer.
此处可能存在不合适展示的内容,页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容,可点击提交进行申诉,我们将尽快为您处理。