chromium/src
0
Fork 0
Code Activity

Relax "Mechanical updates" requirement for global approvals

Browse Source 
Often reviews take longer than needed just due to getting "rubber stamps" for mechanical changes and some CLs need many such reviewers across multiple directories. Our global approvers process already addresses this concern for the specific case of updating calls to code in common directories. This change relaxes the requirement to empower such OWNERS to use their judgement in deciding when additional OWNERS need to be consulted and when they don't. It also generally encourages the use of this mechanism to avoid unnecessary waste of reviewer time.

Change-Id: Ic0764d2519bb90201490a8f498f205a2f02ea4f7
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6185753
Reviewed-by: Nico Weber <thakis@chromium.org>
Commit-Queue: Rick Byers <rbyers@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1409114}
This commit is contained in:
Rick Byers
2025-01-21 09:56:00 -08:00
committed by Chromium LUCI CQ
parent 656f89e731
commit e848f2efd2
1 changed files with 8 additions and 3 deletions

11
docs/code_reviews.md

@@ -247,10 +247,15 @@ file (and line) in the patch has been appropriately reviewed.
For one-off CLs, API owners of `base`, `build`, `content`,
`third_party/blink/public` and `url` can `Owners-Override +1` a change to their
APIs to avoid waiting for rubberstamp +1s from affected directories' owners.
This should only be used for mechanical updates to the affected directories.
This should only be used for mechanical updates, but global approvers are free
to use their judgement in determining which mechanical changes they understand
well enough to approve (rather than limit strictly to calls into code
they own).
If you are making one-off CLs that touch many directories and cannot be
handled by the global approvers, you can ask one of Chrome ATLs.
For a change that impacts many directories but doesn't need area-specific
expertise to review, please ask any global approver or Chrome ATL to
approve the change rather than incur unnecessary review cost on a larger number
of reviewers.
### Large Scale Changes
You can use the [Large Scale Changes](process/lsc/large_scale_changes.md)