On Wed, Jan 20, 2016 at 1:51 AM, Brett Cannon <brett@python.org> wrote:
Bot to handle pull request merging
''''''''''''''''''''''''''''''''''
As stated in the section entitled
"`Document steps to commit a pull request`_", the desire is to
maintain a linear history for cpython. Unfortunately,
Github's [#github]_ web-based workflow does not support a linear
history. Because of this, a bot should be written to substitute for
GitHub's in-browser commit abilities.

To start, the bot should accept commands to commit a pull request
against a list of branches. This allows for committing a pull request
that fixes a bug in multiple versions of Python.

More advanced features such as a commit queue can come later. This
would linearly apply accepted pull requests and verify that the
commits did not interfere with each other by running the test suite
and backing out commits if the test run failed. To help facilitate
the speed of testing, all patches committed since the last test run
can be applied and run in a single test run as the optimistic
assumption is that the patches will work in tandem.

Inspiration or basis of the bot could be taken from pre-existig bots
such as Homu [#homu]_ or Zuul [#zuul]_.



From the experience on both OpenShift [1] and Kubernetes [2] I know there's a need to
rerun tests quite frequently (flakes, errors, etc). One option is to close and re-open the issue to
trigger the integrated CI services to re-run, which is cumbersome imho. Both of the aforementioned
projects have testing bots. The one in orgin [1] is more sophisticated in that it allows core-devs
running finer grained tests before actually merging the PR. The merge bot runs quite bit
of the tests, but not all, possible examples include benchmarks.
Just a food for thought ;)

Maciej


[1] https://github.com/openshift/origin/
[2] https://github.com/kubernetes/kubernetes