[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