commit e0b05955fdfab198bada3fa7a023e0d7431889b6
author Stefan Beller <sbeller@google.com> Mon Jun 08 15:21:35 2015 -0700
committer Stefan Beller <sbeller@google.com> Wed Jul 01 09:23:15 2015 -0700
tree fd17ceefecede7b35d5db744ded709cbb5937310
parent 36a5b23a325c862739ddfc4cbbda79fb3e026c87

Kill the MergeQueue

The MergeQueue is a historical artifact of Gerrit from the time when
accepting submissions and merging was performed on different machines.
Nowadays this is done in the same process, so we do not require an
intermediate queue anymore (also the SUBMITTED state is superfluous).

This change will directly integrate a submission or refuse to do so
and complain to the user. Many user complaints about Gerrit at Google can
be translated to the existence of the MergeQueue as when something goes
wrong in the back end, all the user sees is a "SUBMITTED, MERGE PENDING"
state with delayed information when this is actually merged or if
there is a problem they need to address. This is an unfortunate user
experience, as patience is hard.

A common work flow is to submit a set of changes on one branch by submitting
the later changes of the branch first, such that these enter the merge
pending state and on submitting the first patch of the branch, all the
changes get integrated at once (such as by a single merge commit performed
by Gerrit).

This behavior doesn't work any more with this change, but you'd rather get
a notification when trying to merge a later change of the branch.
That work flow however will be enabled again in another patch of this
topic, when change submission also submits all changes it depends on.

I just don't want to bundle that with this change (as (a) this is already
a large change and (b) it is changing fundamental behavior).

Change-Id: I0c43b16a216db2a82aa0e59375a8a43482bb3b45