- 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.
The --no-push parameter allows you to test changes locally first. Then you can use --continue to finish the backport and open the PR:
Discussion: https://github.com/python/core-workflow/issues/78 Implementation: https://github.com/python/core-workflow/pull/84
By the way, instead of only using the sha1 to build the branch name,
it would be nice to add also the bpo number.
It's possible, but remember not all PRs have bpo-issue, eg those with
trivial label.
In that case, what should the backport branch be?
So we might end up with two backport branch name patterns, eg
backport-bpo-NNNN- and backport-sha1 for the trivial PRs ?
Thanks :)
Mariatta Wijaya
On Wed, May 17, 2017 at 11:26 AM, Victor Stinner victor.stinner@gmail.com wrote:
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
python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/