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. =)
