Change was submitted unintentionally; an external user was screwing around and CQ+1d it. It has been reverted.

How did a random external user get access to CQ +1 it?

Change in question was: https://chromium-review.googlesource.com/c/chromiumos/platform/crostestutils/+/982748

I discussed with vapier@ out-of-band; any registered user being able to CQ+1 is WAI. In theory this shouldn't be a problem since you need a CR+2 first, but clearly that didn't work out here.

I also opened  crbug.com/851094 , which could provide a mitigation for this issue.

the revert has since landed, so i think we're all set here
  https://chromium-review.googlesource.com/1093276

afaict, that user has also been banned.  i had noticed them spamming CLs, but i didn't see they had set CQ+1 else i would have stomped it :(.

Re c#4:

This doesn't sound necessarily right.  In the past we've told people to V+1 should be marked before the reviewers should start reviewing.  So it's quite possible for a change to have V+1, get reviewed for CR+2, and then the original author decide it's not ready for submission for whatever reason (eg missing another change that didn't have dependencies properly specified, or waiting for an infra push).  I'm guessing most times people won't go back and remove the V+1, and instead will wait on the CQ+1.

I feel like CQ+1 for random changes should be allowed for those with +2 capabilities but not just drive bys.

restricting CQ+1 to CR+2 means the external people (including partners) that post CLs need to constantly bug a committer to get something added to the CQ.  which is even more annoying when the CQ is flaky and needs to be retried.

I meant for random changes that the registered user is not associated with.

I think if you're the author/owner of the change, allow CQ+1 still.  Otherwise, only allow it if you have CR+2.

Offline we discussed restricting CQ+1 to people who have signed a CLA. Currently that isn't possible as we don't have a Gerrit group reflecting CLA signers, but it seems feasible and would give at least a slightly higher barrier.

we could make the CQ bots inspect every CL to see who has set CQ+1, but it isn't something we can do based on a gerrit query alone.  i want to say we've had partner teams work together to verify/commit-queue, but it isn't a common scenario.

considering we've had 1 bad CQ+1 actor out of ~100k+ CLs, i'm not too hung up on locking it all down.  since we want to check CLAs anyways, that might be sufficient to deter further noise like this.  see  issue 851094  for more details there.

I got a +2 for the CL but didn't want to land the CL until all reviewers were happy. The CL was stale by the time the spammer CQ+1 it.