New issue
Advanced search Search tips

Issue 852850 link

Starred by 9 users

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 3
Type: Feature

Blocking:
issue 748644



Sign in to add a comment

change Code-Review to be sticky for chromiumos ACLs

Project Member Reported by vapier@chromium.org, Jun 14 2018

Issue description

in order to align with other code review systems that Chromium OS devs use (critique, Chromium, etc...), lets make Code-Review sticky across patchsets.  this is also required in order to sanely support OWNERS (issue 748644).

there are some security concerns we need to iron out wrt public code reviews.  namely, public people being able to upload new patchsets to CLs that have Code-Review +2, then setting Verified/Commit-Queue on the new version w/out review.

team discussion with some ideas about mitigation:
  https://groups.google.com/a/chromium.org/d/topic/chromium-os-dev/Y4UQHzf6ucE/discussion

we need to figure out what's feasible and where: either in Gerrit/ACLs directly, or adding more logic to our CQ bot, or something else.

in the mean time, we should be able to make Code-Review sticky on chrome-internal as it doesn't have the same issue (for the most part ... anyone with access is implicitly trusted either as an employee or a business partner).
 

Comment 1 by sjg@chromium.org, Jun 14 2018

Cc: sjg@chromium.org
Why is this blocking crbug.com/748644?
Are you saying that you dont want to enforce "only owners can +2 the file they own" if they'll have to keep +2-ing each file at each revision? 
I can see how that would introduce terrible coordination problems (see 5 people to +2 each patch-set), but is "sticky +2" the right solution for it?


Components: -Infra>Client>ChromeOS>Build

Sign in to add a comment