Issue 3751: A "Rebase if Necessary" submit type that invalidates the Verified+1
Status:  New
Owner: ----
Reported by tsuna...@gmail.com, Jan 7 (3 days ago)
The "Rebase if Necessary" submit type exposes a hole in the usual Gerrit+Jenkins CI integration: when Gerrit rebases a change, and the rebase passes without a conflict, it doesn't mean that the resulting code still works.  Unfortunately, Gerrit will then submit the change right away, instead of invalidating the Verified+1 and triggering a new event to notify Jenkins of a new patchset following the rebase.

The flow should be:
- Human completes a review, grants a Code-Review+2, clicks the Submit button.
- Gerrit realizes the change can't fast-forward, and rebases it.
- The rebase succeeds. Gerrit revokes the Verified+1 and triggers an event for downstream tools like Jenkins to pick up the new patch set.
- Once the Verified+1 is granted again, Gerrit automatically submits the change.  If the change doesn't fast-forward, then go back to step 2 again.

This flow guarantees that no broken change can be submitted (as per the CI system), whereas the current "Rebase if Necessary" submit type can lead to code that doesn't even compile to be submitted by mistake due to a logical (as opposed to textual) conflict.

Note that this can be worked around by using Fast Forward Only as the submit type, but this is not tractable in practice, because it makes developers waste a lot of time as they constantly have to manually rebase and republish new patchsets in projects with a lot of activity.

If there is another way to ensure that changes always get verified by a CI system before being submitted without requiring constant manual intervention like in Fast Forward Only, please let me know.