[core-workflow] Longer term idea: consider Rust's homu for CPython merge gating

[Nick Coghlan]

On 4 January 2016 at 07:23, Guido van Rossum <guido at python.org> wrote:
> Ah, the last part there is a nice algorithm. It determines the intended
> merge order when patches are submitted to the queue, then runs tests for
> multiple patches in parallel. So, assuming most patches pass their tests,
> the rate at which patches can land is limited only by how fast it can run
> parallelized tests, and as long as the queue isn't congested, each patch
> lands roughly as soon as its tests succeed.

Yeah, I first saw a talk on it at linux.conf.au a couple of years ago,
and was really impressed. They have a good write-up on the system
here: http://docs.openstack.org/infra/zuul/gating.html

For CPython though, OpenHub indicates our commit rate is on the order
of 15 per day (5754 commits in the last 12 months), so even if GitHub
gets us a nice uptick in landing submitted patches, we still have a
lot of headroom before the main bottleneck becomes anything other than
availability of reviewers.

Cheers,
Nick.

P.S. While I think it would be overkill for CPython, folks working
with distributed systems may also be interested in a neat system
called ElasticRecheck that OpenStack use to identify intermittent
failures based on patterns detected in log files:
http://docs.openstack.org/infra/elastic-recheck/readme.html#idea

Relevant dashboard for the OpenStack integrated release gate:
http://status.openstack.org/elastic-recheck/

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia