Mailman 3 June 2017 - core-workflow

Auto labeling PRs based on what stage they're in
by Brett Cannon July 22, 2017

July 22, 2017

I don't know about the rest of you, but I want an easy way to glance at a pull request and know what it's currently blocking it from being merged (if I'm wrong then let me know). I opened https://github.com/python/core-workflow/issues/94 for this idea, but I figured what the exact stages should be deserves a wider discussion. The stages I see are: 1. *Awaiting first review*: no one has reviewed the PR 2. *Awaiting core review*: a non-core dev has reviewed the PR, but there still needs to be that initial core review (still not sure if this is worth the distinction or how complex it will make the code, but it may encourage people to help in the reviewing process instead of automatically diving into coding if their review leads to a visible stage change) 3. *Awaiting changes*: a review has been done, but changes were requested (probably wouldn't reach this stage for non-core reviews; a bit tough to block on a non-core review as their asks may not be reasonable and so shouldn't automatically signal that what someone that they must do what is requested of them in that instance) 4. *Awaiting Nth review/re-review*: the PR submitter believes all the requests have been addressed in all reviews and so is waiting on the reviewer(s) who requested changes to review again (will need to provide a way to leave a message that signals to Bedevere that the submitter feels ready for another review) 5. *Awaiting merge*: all reviews approve of the PR (we could also drop the "awaiting core review" stage and go straight here even for non-core reviews that are all approvals, but maybe that's leaning on non-core devs too much and giving false hope to PR submitters?) Am I missing a step?

3 11

Looking for reviewers on a PR to add a check for whitespace
by Brett Cannon June 23, 2017

June 23, 2017

https://github.com/python/core-workflow/issues/3 is tracking adding a check for proper whitespace in PRs as we had that on hg.python.org but we are missing it on GitHub. I have a PR at https://github.com/python/cpython/pull/2367 that I think does the right thing, but I would appreciate a quick review to make sure I didn't miss anything since this will block PRs if I get it wrong. :)

1 0

Do we still have mention-bot?
by Mariatta Wijaya June 12, 2017

June 12, 2017

The newest PRs in CPython don't have any comment from mention-bot.

2 1

Creating a PyPI account for workflow tools
by Brett Cannon June 10, 2017

June 10, 2017

I'm thinking we should create an account to own things like cherry_picker and blurb for when they get put on PyPI. I'm not sure if it should be specific to core-workflow or generic to python-dev, though? Anyone have an opinion on the scope of the account?

2 1

Requirements to make AppVeyor a required status check
by Brett Cannon June 3, 2017

June 3, 2017

https://github.com/python/core-workflow/issues/41 is tracking the idea of requiring AppVeyor to pass for a PR to be mergeable so as to prevent people breaking Windows. Since two commits fixing tests for AppVeyor just landed I want to see if we can go a week without AppVeyor failing because of AppVeyor itself. If that threshold is met, I plan to turn on the requirement. I'm stating this here mostly so people know to update the issue if a transient failure is spotted so that it can be fixed and the one-week clock can be reset.

2 2