[core-workflow] Starting the improved workflow discussion again

[R. David Murray]

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.

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.

--David