Most likely isn't needed since we moved to V2, people can use check-patch if they want merge gating.

Some developer interest in gating:

Project ovirt-engine-api-model_4.0_build-artifacts-fc24-x86_64 is failing

This issue had been raised for discussion in the oVirt devel ML:

Merge gating in Gerrit
Gerrit parallel patch handling and CI (Or, why did my code fail post-merge)

So far the responses seem to indicate that automated rebasing is important (And developers are not keen on doing it themselves). So we probably have to use Zuul (Re focus on ).

One issue that brought to my attention - What happens when patches are created in parallel by multiple programmers.

Suppose the following scenario:
master <- PP1
master <- PP2

Lets assume PP1 gets sent to the gate job and gets merged.

If PP2 not gets sent to the gate job it may succeed and try to merge it. If the repo is configured to "Rebase If Necessary" Gerrit will automatically try to rebase PP2 on top of PP1 and merge it if that succeeds.
The code we will end up with is this:

master <- PP1 <- PP2

But this is different then what the gate job tested which was:

master <- PP2

The way to solve this is to configure the repos to "Fast Forwared Only". In that case merging PP2 will fail and Gerrit will force the devs to rebase PP2 and re-send it to the gate.

But please note - changing the repos to be "Fast Forwared Only" would probably also fix all cases where check_patch did not run on the right code. This may reduce the motivation for gate jobs.

Ok after checking some more - if P2 is submitted and them a new patch-set is pushed to P1 and submitted to be merged, P2 will not be merged, instead Gerrit will show a message like this:

Change cannot be merged due to unsatisfiable dependencies.

The following dependency errors were found:

Depends on patch set 2 of Ifebfb074, however the current patch set is 3.

Please rebase the change and upload a replacement commit.

When the user rebases P2 (either manually or with Gerrit's "rebase" button) then it will go back to being reviewed and the flags will be zeroed.

Bottom line - As long as projects are configure to use "Fast Forwared Only" or "Rebase If Necessary", Gerrit makes handling sets of patches very safe (Nothing is ever cherry-picked) so its safe to gate using only Jenkins and let the jobs checkout the patches.