> > Requiring Travis to pass
Yes please. Cherry-picking working out? Works for me. And I've done a lot of this :) are the labels for cherry-picking working out? I like the [3.6] Prefix (Thanks Berker for suggesting it originally) I think [cherry-pick for 3.6] label is still useful as a visual cue in the GitHub Web UI, but it does create extra work for core devs to apply the labels. Perhaps won't be an issue once the cherry-pick bot is in place? Anyway, I think we should keep both :) Is the mention bot helpful? > I think if we can reduce the number of reviewers from 5 to 3 or 2, it might reduce the amount of spam people are getting? When someone starts blacklisting themselves from the mention-bot, it just means that another person will now get spammed, and then decided to blacklist themselves too. anything I missed? I'm wishing for an easy way to differentiate/identify PRs where: - It's been reviewed, changes were requested, but author has not responded/made updates. --> so don't bother reviewing - It's been reviewed, changes were requested, and author has updated the PR. --> so it's ready for another look At the moment, both of these scenarios are shown as "Changes Requested" in GitHub web UI. It's hard to determine whether it's time to re-review the PR or not. Maybe we can add [wip] in the title after we requested the change. Once PR author made further changes, they can remove the [wip]. Right now, cherry-picking is very annoying but I'm not sure that > merging would be much better with the PR requirement. I'm looking > forward to automation! I have a semi-automated command line script here: https://github.com/mariatta/chic_a_cherry_picker Please try it out :) I've cherry-picked quite a number of commits with this. Works well when you don't anticipate any merge conflicts :) The command line is something like: $ python -m cherry_picker some-commit-sha1 3.6 3.5 It will do the cherry-pick and opens up web browser for creating the PR, with head and base branches preselected. All you need to do is enter [3.5] or [3.6] in the description, and press the shiny green 'Create Pull Request' button. Related: here's a list of merged PRs that need backporting to 3.6 https://github.com/python/cpython/pulls?utf8=%E2%9C%93&q=is%3Apr%20label%3A%22needs%20backport%20to%203.6%22%20is%3Amerged%20 Overall, I'm positive on the move. Thanks for continuing to shepherd > the migration, Brett! +1.Thanks! Mariatta Wijaya On Sat, Mar 11, 2017 at 8:05 AM, Donald Stufft <don...@stufft.io> wrote: > > On Mar 11, 2017, at 3:03 AM, Zachary Ware <zachary.ware+py...@gmail.com> > wrote: > > > Is the mention bot helpful? (Our config is at > https://github.com/python/cpython/blob/master/.mention-bot and the docs > are > at https://github.com/facebook/mention-bot) > > > I think so, it has prompted me to give a quick review on a couple of > PRs. It is occasionally annoying, but it's not hard to ignore. I can > see how it would be *very* annoying for anyone who has touched large > swaths of the codebase, though. If there's a way to make it opt-in, > perhaps we could give that a spin? > > > > There’s no way to make it opt-in except by having people explicitly list > what files they want to be notified on (either on an always basis, or on a > “if you couldn’t find enough people through your heuristics” basis). > > — > Donald Stufft > > > > > _______________________________________________ > 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/