On 4 January 2016 at 07:23, Guido van Rossum <[email protected]> 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 | [email protected] | Brisbane, Australia _______________________________________________ core-workflow mailing list [email protected] https://mail.python.org/mailman/listinfo/core-workflow This list is governed by the PSF Code of Conduct: https://www.python.org/psf/codeofconduct
