Split the merger into a separate process

Connect it to Zuul via Gearman.  Any number of mergers may be
deployed.

Directly find the pipeline for a build when processing a result,
so that the procedure is roughly the same for build and merge
results.

The timer trigger currently requires the gerrit trigger also be
configured.  Make that explicit inside of the timer trigger so
that the scheduler API interaction with triggers is cleaner.

Change-Id: I69498813764753c97c426e42d17596c2ef1d87cf

1 files changed, 9 insertions, 0 deletions

diff --git a/NEWS.rst b/NEWS.rst
index ba6c9860e..bd09bfefa 100644
--- a/NEWS.rst
+++ b/NEWS.rst
@@ -3,6 +3,15 @@ Since 2.0.0:
 * The push_change_refs option which specified that Zuul refs should be
   pushed to Gerrit has been removed.
 
+* Git merge operations are now performed in a separate process.  Run
+  at least one instance of the ``zuul-merger`` program which is now
+  included.  Any number of Zuul-Mergers may be run in order to
+  distribute the work of speculatively merging changes into git and
+  serving the results to test workers.  This system is designed to
+  scale out to many servers, but one instance may be co-located with
+  the Zuul server in smaller deployments.  Several configuration
+  options have moved from the ``zuul`` section to ``merger``.
+
 Since 1.3.0:
 
 * The Jenkins launcher is replaced with Gearman launcher.  An internal