In my ideal workflow scenario, these are the steps a patch would take: 1. Issue is created 2. Issue is triaged to have right affected versions, etc. 3. Patch is uploaded 4. CI kicks the patch off for *all* branches and OSs that are affected 5. CI flags what branches and OSs did (not) pass or apply cleanly to 6. If necessary, another patch that works in a specific branch that is affected is uploaded (obviously requires some way to flag that a patch applies to a specific branch, deciding how to deal with Misc/NEWS, etc.) 7. Code review -- with a tool other than Rietveld -- from a core developer with feedback 8. New version of patch uploaded, usual CI kicked off 9. If everything looks good and CI is green, get patch approval from a core dev 10. Approval submits the patch(es) to the appropriate branches 11. CI triggered yet again, and if tests fail then patch(es) are automatically rolled back
Now I realize this is not about to launch immediately. There are changes to Roundup in there, a reliable test suite that actually fails only on failures and not because it's flaky, etc. But the key point here is that everything that can be automated is, and code reviews can occur entirely through a browser. The independent parts I see here are (which probably all require some Roundup integration to be effective): - CI for every patch - A new code review tool - Automated/browser-based handling of VCS (e.g., submission, rollback) Once the pieces are in place then they can be tied together and drive each other (e.g., code review tool submitting a patch, CI tool automatically handling rollbacks, etc.), but that is not necessary to make forward progress. I'll let Nick and Donald chime on what exactly their proposals can do today and what they will need to make the magical workflow happen. =)
_______________________________________________ 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
