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.
Fifth, anything I missed? :)
python-committers mailing firstname.lastname@example.org
Code of Conduct: https://www.python.org/psf/codeofconduct/