[Python-checkins] peps: Incorporate PEP 462 feedback

Terry Reedy tjreedy at udel.edu
Mon Jan 27 06:28:15 CET 2014


On 1/26/2014 10:22 PM, nick.coghlan wrote:
> +Terry Reedy has suggested doing an initial filter which specifically looks
> +for approved documentation-only patches (~700 of the 4000+ open CPython
> +issues are pure documentation updates). This approach would avoid several
> +of the issues related to flaky tests and cross-platform testing, while
> +still allowing the rest of the automation flows to be worked out (such as
> +how to push a patch into the merge queue).
> +
> +The one downside to this approach is that Zuul wouldn't have complete
> +control of the merge process as it usually expects, so there would
> +potentially be additional coordination needed around that.

An essential part of my idea is that Zuul *would* have complete control 
while pushing doc patches to avoid the otherwise inevitable push races. 
Initially, this would be for a part of every day. While it has control, 
I would expect it to push doc patches at intervals of perhaps a minute, 
or even more rapidly with parallel testing. (Since doc patch rarely 
interfere and would be expected to apply after pre-testing, little 
speculative testing would need to be tossed.)

> +It may be worth keeping this approach as a fallback option if the initial
> +deployment proves to have more trouble with test reliability than is
> +anticipated.

I think a doc queue should be a permanent part of the system. There 
would always be doc-only patches -- and I suspect even more than now. 
One of the types of jobs on the main queue could be a periodic 'push all 
pending doc patches' job. I would then think we should try splitting 
code + doc patches into a code patch, pushed first, and a doc patch, 
added to the doc queue if the code patch succeeded.

Terry




More information about the Python-checkins mailing list