[python-committers] 4 weeks with the new workflow: what needs changing?

[Donald Stufft]

> On Mar 10, 2017, at 5:13 PM, Brett Cannon <brett at 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 <https://github.com/python/cpython/blob/master/.mention-bot> and the docs are at https://github.com/facebook/mention-bot <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 <https://github.com/python/cpython/blob/master/.codecov.yml> and docs at https://docs.codecov.io/docs/codecov-yaml <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 <https://github.com/python/core-workflow/issues>. Specifically, https://github.com/python/core-workflow/issues/6 <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 <https://github.com/python/core-workflow/issues/31>.
> 
> Fourth, the lack of messages showing up on bugs.python.org <http://bugs.python.org/> after a commit is being tracked at http://psf.upfronthosting.co.za/roundup/meta/issue613 <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 at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/


—
Donald Stufft



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20170310/2d609fb7/attachment-0001.html>