On 4 January 2016 at 07:23, Guido van Rossum
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@gmail.com | Brisbane, Australia