On 11 March 2017 at 08:13, Brett Cannon <br...@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 think this is a good thing, but it's annoying some times when processing a change that needs to go to all 4 currently active branches. The other case where it's annoying is when backfilling NEWS entries - if there's a backlog, then it still takes a while to get to the point of Travis detecting that there isn't actually anything for Travis to do.
It's probably worth talking to the PSF and Travis CI to see if it's possible to speed things up a bit or get more parallel workers (some of the PSF's larger sponsors are actually providing in-kind donations of services rather than purely financial sponsorship). > > - 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) > > I'm still a fan of cherry picking, as it simplifies the typical case to "fix master, worry about backports later". > > - 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) > > There was at least one PR submitter confused in IRC today as to whether or not the "Needs backport to..." labels were asking *them* to do something. > > - 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) > > Honestly, I'm starting to think we're going to have to tweak it a bit (or come up with our own variant) to get something suitable for a primarily volunteer-based development team, rather than the primarily paid teams that I believe the mention-bot was originally written for. As it currently stands, it's veering too far into burnout-inducing "Have you done enough for CPython lately?" territory for my liking: https://nolanlawson.com/2017/03/05/what-it-feels-like-to-be-an-open-source-maintainer/ So I'd personally vote for this to be turned off until there's a way to run it in an *opt-in* configuration, rather than the current opt-out setup. Another possibility would be to tweak the GitHub/bugs.python.org bridge to add comments for PR *creation*, such that everyone on the nosy list gets the alert that the PR exists (hence implicitly requesting a review from the maintainers following the issue). That way things would better align with the entries we've added to the experts index. > > - 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) > > I was going to ask if there was a way to get the "Details" link to go straight to a useful report, but it seems like that may have already been tweaked. > 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. > For the cherry-picking automation, I've been very happy with Mariatta's utility, and I believe that with a few robustness tweaks and a conflict-avoiding approach to handling Misc/NEWS it would be up to the task of generating the actual PRs as well. (The other side of the bot that actually handled the interaction with GitHub could presumably be modeled on the way the existing knights-who-say-ni bot works) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
_______________________________________________ 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/
