[core-workflow] Starting the improved workflow discussion again
Ezio Melotti
ezio.melotti at gmail.com
Tue Jul 21 20:14:36 CEST 2015
On Mon, Jul 20, 2015 at 10:49 PM, Brett Cannon <bcannon at gmail.com> wrote:
> In my ideal workflow scenario, these are the steps a patch would take:
>
> Issue is created
> Issue is triaged to have right affected versions, etc.
> Patch is uploaded
> CI kicks the patch off for all branches and OSs that are affected
> CI flags what branches and OSs did (not) pass or apply cleanly to
Checking if a patch applies cleanly on the active branches can be done
with a Roundup detector.
The detector can also add this information in the patch metadata.
We currently have two GSoC students working on Roundup:
1) one is adding a REST API that will make a lot of these things simpler;
2) the other so far worked on an hg extension that talks with Roundup
and is currently working on a patch analysis feature that figures out
which files are affected (and could also check which branches the
patch applies to).
The patch analysis shouldn't be too expensive, and can probably been
done for each patch as soon as it's uploaded.
These and other tracker improvements will likely get integrated around
the end of GSoC.
Best Regards,
Ezio Melotti
> 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.)
> Code review -- with a tool other than Rietveld -- from a core developer with
> feedback
> New version of patch uploaded, usual CI kicked off
> If everything looks good and CI is green, get patch approval from a core dev
> Approval submits the patch(es) to the appropriate branches
> 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
> core-workflow at python.org
> https://mail.python.org/mailman/listinfo/core-workflow
> This list is governed by the PSF Code of Conduct:
> https://www.python.org/psf/codeofconduct
More information about the core-workflow
mailing list