0

Cross-link the New Port Policy with the Contributing guide.

Both discuss the addition of new ports/platforms.

Change-Id: I953e70bdc55a3a78eabd0ec1a03b32cb6fd2b819
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3708565
Reviewed-by: Erik Staab <estaab@chromium.org>
Commit-Queue: Robert Sesek <rsesek@chromium.org>
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1014959}
This commit is contained in:
Robert Sesek
2022-06-16 16:56:39 +00:00
committed by Chromium LUCI CQ
parent dd8b455699
commit 3966bfdb39
2 changed files with 9 additions and 3 deletions

@ -338,7 +338,8 @@ general rules of thumb can be helpful in navigating how to structure changes:
that do not increase the cost of maintaining Chromium's supported
architectures / platforms (e.g., adding one ifdef branch for an unsupported
architecture / platform is fine but introducing new abstractions in the
codebase is problematic).
codebase is problematic). See the [new port policy](new_port_policy.md) for
further guidance.
- **Code should only be moved to a central location (e.g., //base) when
multiple consumers would benefit.** We should resist the temptation to

@ -1,6 +1,12 @@
# Policy for Adding a New Port
Since every new port for Chromium has a maintenance cost, here are some guidelines for when the project will accept a new port.
**Before the Chromium project first starts accepting patches for new ports, the
new port/platform must be approved by project leadership.** See the
[contributing guidelines](contributing.md#Code-guidelines) for how to get
approval for new architectures, platforms, or sub-projects.
Since every new port for Chromium has a maintenance cost, here are some
expectations of new ports that the project accepts:
## Expectations
@ -9,4 +15,3 @@ Since every new port for Chromium has a maintenance cost, here are some guidelin
* Chromium engineers are not expected to maintain them.
* As much as possible, try to use existing branches/ifdefs.
* While changes in src/base are unavoidable, higher level directories shouldn't have to change. i.e. existing porting APIs should be used. We would not accept new rendering pipelines as an example.
* Send an email to [src/OWNERS](https://chromium.googlesource.com/chromium/src/+/main/ENG_REVIEW_OWNERS) for approval.