On 27 January 2014 15:28, Terry Reedy tjreedy@udel.edu wrote:
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.)
"Exclusive control some of the time" is not the same thing as "exclusive control". It's not an impossible idea, but certainly not the way Zuul is currently designed to work :)
+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.
That seems like added complexity for little gain - note that we can make the test runner smart about how it handles doc-only patches, by just checking the docs build and skipping the test run.
Cheers, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
-
Nick Coghlan