[python-committers] Feedback on the new CPython workflow

[Victor Stinner]

Hi,

I wanted to wait a little bit before giving back my feedback on the
new workflow. I just attend Brett Canon's talk at the Language Summit.
So here are my misc notes on the new workflow.

* Is there anyone already working on the workflow who would like to
get a grant (money!) from the PSF?

* If I want to share a change to review but it must not be merged,
would it be possible to prevent merge by mistake? Maybe add [WIP] to
the title and modify our bot to mark the "build" as failed? For
example, I wrote a patch which depends on a different patch but I
didn't want to create a patch serie since it didn't make sense.

* AppVeyor is now quite stable. I fixed a few unstable tests. I
suggest to mark this CI as mandatory. The CI is as fast or even faster
than Travis CI! But it seems like it accepts less jobs in parallel :-/
It might be an issue if we get a huge number of PR in a short period
(ex: during an event like Pycon US).

* Currently, cherry-picker works a single step. It would be nice to
have at least 2 steps: first cherry-pick locally, then allow to review
the patch locally and run some specific tests, and then send the PR.
By the way, instead of only using the sha1 to build the branch name,
it would be nice to add also the bpo number.

* I suggest to track backports at bpo since an issue tracks all PR and
it seems like most core developers want to put most informations in
the issue rather than GitHub.

* Find a way to keep the Code coverage job, but don't mark the PR as
failed if the coverage is considered as "failed"? It's strange to see
a long list of PR with the red sign (failed) whereas Travis and
AppVeyor passed.

I have a lot of other minor remarks, but I prefer to stop here ;-)

Victor