<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Fri, 22 Jan 2016 at 14:44 Maciej Szulik <<a href="mailto:soltysh@gmail.com">soltysh@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Jan 20, 2016 at 1:51 AM, Brett Cannon <span dir="ltr"><<a href="mailto:brett@python.org" target="_blank">brett@python.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Bot to handle pull request merging<div><div><div>''''''''''''''''''''''''''''''''''</div><div>As stated in the section entitled</div><div>"`Document steps to commit a pull request`_", the desire is to</div><div>maintain a linear history for cpython. Unfortunately,</div><div>Github's [#github]_ web-based workflow does not support a linear</div><div>history. Because of this, a bot should be written to substitute for</div><div>GitHub's in-browser commit abilities.</div><div><br></div><div>To start, the bot should accept commands to commit a pull request</div><div>against a list of branches. This allows for committing a pull request</div><div>that fixes a bug in multiple versions of Python.</div><div><br></div><div>More advanced features such as a commit queue can come later. This</div><div>would linearly apply accepted pull requests and verify that the</div><div>commits did not interfere with each other by running the test suite</div><div>and backing out commits if the test run failed. To help facilitate</div><div>the speed of testing, all patches committed since the last test run</div><div>can be applied and run in a single test run as the optimistic</div><div>assumption is that the patches will work in tandem.</div><div><br></div><div>Inspiration or basis of the bot could be taken from pre-existig bots</div><div>such as Homu [#homu]_ or Zuul [#zuul]_.</div><div><br></div><br></div></div></div></blockquote></div><br></div></div><div dir="ltr"><div class="gmail_extra">From the experience on both OpenShift [1] and Kubernetes [2] I know there's a need to <br></div><div class="gmail_extra">rerun tests quite frequently (flakes, errors, etc). One option is to close and re-open the issue to <br></div><div class="gmail_extra">trigger the integrated CI services to re-run, which is cumbersome imho. Both of the aforementioned <br>projects have testing bots. The one in orgin [1] is more sophisticated in that it allows core-devs<br></div><div class="gmail_extra">running finer grained tests before actually merging the PR. The merge bot runs quite bit<br></div><div class="gmail_extra">of the tests, but not all, possible examples include benchmarks. <br></div><div class="gmail_extra">Just a food for thought ;)<br></div></div></blockquote><div><br></div><div>Thanks for the warning, Maciej. I have added a note that test re-runs should be considered in its design. Will go out with the next set of updates (hopefully tomorrow once I find out if anyone actually uses the sys._mercurial attribute). </div></div></div>