summaryrefslogtreecommitdiff
path: root/chromium/docs/contributing.md
diff options
context:
space:
mode:
authorAllan Sandfeld Jensen <allan.jensen@qt.io>2022-09-29 16:16:15 +0200
committerAllan Sandfeld Jensen <allan.jensen@qt.io>2022-11-09 10:04:06 +0000
commita95a7417ad456115a1ef2da4bb8320531c0821f1 (patch)
treeedcd59279e486d2fd4a8f88a7ed025bcf925c6e6 /chromium/docs/contributing.md
parent33fc33aa94d4add0878ec30dc818e34e1dd3cc2a (diff)
downloadqtwebengine-chromium-a95a7417ad456115a1ef2da4bb8320531c0821f1.tar.gz
BASELINE: Update Chromium to 106.0.5249.126
Change-Id: Ib0bb21c437a7d1686e21c33f2d329f2ac425b7ab Reviewed-on: https://codereview.qt-project.org/c/qt/qtwebengine-chromium/+/438936 Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
Diffstat (limited to 'chromium/docs/contributing.md')
-rw-r--r--chromium/docs/contributing.md16
1 files changed, 9 insertions, 7 deletions
diff --git a/chromium/docs/contributing.md b/chromium/docs/contributing.md
index ff024379d4d..b0f1288da6c 100644
--- a/chromium/docs/contributing.md
+++ b/chromium/docs/contributing.md
@@ -327,18 +327,20 @@ general rules of thumb can be helpful in navigating how to structure changes:
Chromium project.** This is important so developers can understand the
constraints informing a design decision. Those constraints should be apparent
from the scope of code within the boundary of the project and its various
- repositories. In other words, for each line of code, you should be able to
- find a product in the Chromium repositories that depends on that line of code
- or else the line of code should be removed.
+ repositories. In general, for each line of code, you should be able to find a
+ product in the Chromium repositories that depends on that line of code or else
+ the line of code should be removed.
Completely new additions to the project (e.g., support for a new OS or
architecture, or a new top-level directory for a new sub-project) must be
approved by chrome-eng-review@google.com. For long-term maintenance reasons,
we will accept only things that are used by the Chromium project and things
- 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).
+ whose benefit to Chromium outweighs any cost increase in maintaining
+ Chromium's supported architectures / platforms (e.g. adding one ifdef branch
+ for an unsupported architecture / platform has negligible cost and is likely
+ fine, but introducing new abstractions in the code has a high cost and would
+ need to provide Chromium with corresponding benefit). 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