[core-workflow] Updated draft of PEP 512

[Brett Cannon]

On Fri, 22 Jan 2016 at 14:44 Maciej Szulik <soltysh at gmail.com> wrote:

> On Wed, Jan 20, 2016 at 1:51 AM, Brett Cannon <brett at 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 ;)
>

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).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20160123/daf7d394/attachment.html>