On Wed, 17 May 2017 at 11:27 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. > So in this instance couldn't you just not submit the PR until the dependent PR has been accepted? IOW could you just keep the change in your fork until it's ready for review? > > * 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). > https://github.com/python/core-workflow/issues/41 (I also have https://github.com/python/core-workflow/issues/91 for turning on macOS support in Travis to test it out, but this wouldn't be required to pass). > > * 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. > The problem with that is the backport is about cherry-picking the submitted change, not the issue under discussion so there's a disconnect there. Plus we don't typically remove what versions of Python are affected by an issue as we fix things so this would change how we track to what branch we backport to. > > * 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. > That is already done for new PRs and should be true for all branches (and if it isn't then https://github.com/python/core-workflow/issues/81 will make that true for all branches).
_______________________________________________ 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/
