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.

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.

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
Code of Conduct: https://www.python.org/psf/codeofconduct/

Donald Stufft