On Mar 10, 2017, at 5:13 PM, Brett Cannon <brett@python.org> wrote:

I can't believe it's been 4 weeks. It feels like it was ages/yesterday when we moved. :)

First, I hope people are not regretting letting/having me make this migration. I know there have been some things to work through (and others still to come), but I hope this is all a net positive (either now or in the near future).

Second, I wanted to get initial feedback on things we can easily tweak:
Requiring Travis to pass (I really don't want to turn this off as we already had a broken build when I temporarily turned it off at someone's request when Travis was backed up from the AWS S3 outage; I also don't plan to make AppVeyor required unless there's a way to make it be skipped for doc-only changes)

I agree with not wanting to turn off mandatory CI. It’d be nice to get as much coverage of platforms as we can as required CI on a per-merge basis, but there is obviously a balance to be had here between quick responses and maximal coverage.

Cherry-picking working out? (We can go back to forward merging if people really want to, but I think long-term cherry-picking will allow for more automation)
Along with that, are the labels for cherry-picking working out? (Some devs seem to like using title labels like `[3.6]` to flag cherry-picks so it's more obvious in emails so I don't know if the labels are really that useful)

For the couple of things I’ve done I’ve not had any problem with it.

One thing I noticed that might be weird is that Misc/NEWS is kind of weird now. On `master` it only contains entries for 3.6 up until the point that 3.6 was branched off of `master` (or more specifically in this case, since we migrated to a cherry-picking work flow). This will likely cause some issues now that I think about it with the stuff in #python/core-workflow#6 because files added to `master` between the last release of X.Y and when X.Y gets branched off of `master` are going to show up as new in X.Y+1. This could be resolved I think by, immediately altering branching X.Y off of `master`, deleting all pending news files and also cherry-picking the “compile” step of say, 3.6 into the `master` branch (and so on up the line). Alternatively still do the delete thing, but make the ``Misc/NEWS`` specific to a particular release series.

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’ve found it helpful thus far. It’s poked me on a few issues and I jumped in and gave a review on them. There is too much churn in python/cpython for me to get notified of every issue. I suspect as we get more people submitting PRs (and thus, retaining author) it will get more diverse in who it notifies as well.

Anything to tweak about the coverage bot and reports? (Our config is at https://github.com/python/cpython/blob/master/.codecov.yml and docs at https://docs.codecov.io/docs/codecov-yaml)
Third, I wanted to point out some of the more critical discussions going on at https://github.com/python/core-workflow/issues. Specifically, https://github.com/python/core-workflow/issues/6 is working towards a solution for Misc/NEWS so if you care about the final solution you should participate there. After Misc/NEWS is solved the next step becomes solving the cherry-picking overhead with a more automated approach. We are also discussing closed branches to make the list of branches more manageable at https://github.com/python/core-workflow/issues/31.

Fourth, the lack of messages showing up on bugs.python.org after a commit is being tracked at http://psf.upfronthosting.co.za/roundup/meta/issue613. I'm sure Ezio and Maciej would appreciate any help people may be able to volunteer to help in solving the problem.

Fifth, anything I missed? :)
_______________________________________________
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/