On Sun, 12 Mar 2017 at 04:10 Nick Coghlan <ncogh...@gmail.com> wrote:
> 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). > Already have. We got 25 jobs shared between python, pypa, and pyca thanks to Donald. At this point the best option we have to speed things up is to consider dropping tests (e.g. do we want to keep the C++ header test, or do we really need to test both clang and gcc?). > > - 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. > I'm not quite sure how to solve that one beyond what is in the devguide. And did anyone have an opinion on (I think) Mariatta's idea to cut the labels down to versions + "needs backport" and "cherry-pick"? > > > > - 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) > > 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. > Since there doesn't seem to be strong support I'm leaning towards switching it off as well, but I will wait until there's been at least a weekday around the globe for people to notice this email thread. > > 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) > We could consider moving the script to the core-workflow repo if Mariatta is amenable so that we can all contribute towards improving it and making it the short/medium-term solution until we have some bot to do the work (which could theoretically use the script itself).
_______________________________________________ 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/
