Gerrit now lets admins decide if they want to optimize speed of
operations by omitting 'mergeable' from the change index and ChangeInfo
in API responses. Omitting 'mergeable' from the change index also means
that Gerrit will not reindex all open changes when the target ref
advances. This operation is especially costly on repositories with a
large number of open changes.
Prior to this commit, this was controlled by the following switches:
gerrit.config:
- change.api.excludeChangeInMergeable: Skip 'mergable' in API
responses.
- index.change.indexMergeable: Skip mergeable when indexing.
ListChangeOptions:
- SKIP_MERGEABLE: Skip 'mergeable' on-demand in the query at hand.
These three knobs make it hard to get this right. In addition, they
allow for potentially dangerous behavior when
change.api.excludeChangeInMergeable=false and
index.change.indexMergeable=false since this forces Gerrit to recompute
the 'mergeability' bit potentially many times when returning query
responses.
This commit cleans up this landscape by deprecating the SKIP_MERGEABLE
change list option. The idea is that Gerrit admins need to be
prescriptive about the performance behavior of their systems. So the
behavior should be controlled system-wide instead of per-request.
The two Gerrit configs are unified into an enum that allows us to get
rid of the dangerous behavior. The possible states of
change.mergeabilityComputationBehavior are:
- API_REF_UPDATED_AND_CHANGE_REINDEX
- REF_UPDATED_AND_CHANGE_REINDEX
- NEVER
Change-Id: I01c87f6f6d731121b51301f403fa92de3e4c72f7
a4824dbce2