> > * 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.stin...@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/ >
_______________________________________________ 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/
