[core-workflow] Starting the improved workflow discussion again

[Brett Cannon]

On Mon, Jul 20, 2015 at 1:36 PM R. David Murray <rdmurray at bitdance.com>
wrote:

> On Mon, 20 Jul 2015 19:49:50 -0000, Brett Cannon <bcannon at gmail.com>
> wrote:
> > 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
>
> This may be a non-starter.  Instead, I believe it will be much more
> practical to have core dev review first, with a way for the core dev to
> trigger the CI run.  Specifically, I as a buildbot owner do not want
> arbitrary patch uploads to be able to run on my servers.  Nor will
> infrastructure allow this on any platform they control (we asked).
>
> If there is a CI system out there that will allow this and whose free
> (or donated) tier will support our test suite, then it might be viable,
> but I doubt very much that it will cover all our platforms.  That may
> not be a blocker, though...this CI could just be a "basic check" run,
> with the buildbots continuing to provide the all-supported-platforms
> (and then some) post-commit check they do now.
>
> On the other hand, steps 1 to 3 are a problem regardless.  It often
> happens that a patch is uploaded before triage is done, and the branches
> are not set correctly.  And you'd need some way to re-trigger a build
> anyway.  So, I think really we want triggered CI builds, not automatic
> ones.
>

That's all very convincing and I'm happy to let CI be a privileged,
triggered event if we stick with buildbots for our testing fleet.


>
> We already have something that Kushal built that will do the triggered
> build for the linux platform...I haven't played with it yet because I
> haven't had time to do any full review/commit cycles since he made it
> available.  It does not yet report back to the tracker, but I don't
> think that will be hard to add (he may have already written the code, in
> fact).  I think it just does default and not all branches, but I'm not
> sure.  Regardless, it is a place to start.
>

I haven't played with it myself for the same reasons as you, David. I'm
very appreciative to have the tool available today, although I would like
to see it integrated with Roundup so I don't have to log into IRC just to
fire off a CI run. Plus Linux obviously doesn't cover everything.

Ideally we would then gate committal on passing CI and then commit it. The
issue with that, though, is possible race conditions on commits where you
would need to run the CI again to verify that the tests all still pass once
the commit landed. So I don't think we can avoid at least two CI runs per
patch (making sure it's basically sound and then verifying that it doesn't
require a rollback).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20150721/e3ee48d2/attachment-0001.html>