Mailman 3 March 2017 - python-committers

I have blocked Wes Turner from the Python org on GitHub
by Brett Cannon 02 Jun '17

02 Jun '17

In the (long) discussion of https://github.com/python/core-workflow/issues/6, Wes Turner began to do his usual posting of lists. People pointed out he was stepping out of line by being somewhat off-topic and seemingly lecturing folks. He posted some of his lists again and then I warned him that if he did it again I would block him for a CoC violation since he did not want to respect anyone's time by taking the time to edit what amount to dumping his personal notes on GitHub. (This is a long-standing issue, BTW, with Wes where he has been warned in other settings like distutils-sig about his posting behaviour.) Unfortunately he did it again for https://github.com/python/core-workflow/issues/66. Since GitHub only has organization-level blocks I have blocked him at that level (I've also already received some +1s from core devs while writing this email for my move, so I know others who have interacted with him also support this decision).

11 16

Spurious bugs.p.o messages
by Antoine Pitrou 01 Apr '17

01 Apr '17

Hello, Just a heads up that the following PR: https://github.com/python/cpython/pull/552/files has generated a lot of spurious PR additions on bugs.python.org, probably because that PR references a lot of issues (example: https://bugs.python.org/issue23839). Perhaps it would be nice to have an upper limit on the number of notified issues when the PR mentions several of them? (I'm sure someone more active than me, such as Victor or Serhiy, got *a lot* of notifications from that PR :-)) Regards Antoine.

5 5

Is clang testing necessary?
by Antoine Pitrou 28 Mar '17

28 Mar '17

Hello, I am curious about the decision to have Travis-CI tests with both clang and gcc. clang is a compiler which strives to be very compatible with gcc. I would understand testing under OS X with clang in addition to Linux with gcc, but I'm skeptical we gain much from testing both gcc and clang under Linux. Also, it lengthens CI times, as clang produces slower code in debug mode than gcc does (because we use "-Og" on gcc). Or perhaps we could switch the clang build to produce a non-debug interpreter (and therefore a faster test suite)? Regards Antoine.

4 6

Signups for 2017 Python Language Summit are now open
by Larry Hastings 27 Mar '17

27 Mar '17

(reposting, cc'ing python-dev) It’s that time again: time to start thinking about the Python Language Summit! The 2017 summit will be held on Wednesday, May 17, from 10am to 4pm, at the Oregon Convention Center in Portland, Oregon, USA. Your befezzled hosts Larry and Barry will once again be at the helm. The summit’s purpose is to disseminate information and spark conversation among core Python developers. It’s our yearly opportunity to get together for an in-person discussion, to review interesting developments of the previous year and hash out where we’re going next. And we have lots to talk about! Since our last summit, Python 3.6 was released, and the main CPython development process has been moved to GitHub. Naturally Python 3.7 development continues apace. Speaking of changes, we’re continuing to evolve the summit. Everyone seemed to like the lightning talks, so we’ll keep those. Everyone seemed to hate us keeping the schedule secret -sorry!- so we’ll make that available beforehand, with the understanding that it’ll be fluid as the day progresses. Due to room size limitations and the yearly increase in participation, we’re limiting summit invitations to just core developers and invited speakers. As usual, we’ll have whiteboards and a projector. But this year we’re adding roaming microphones, so everybody in the room will be able to hear your question! With the help of the ever awesome Ewa, this year we’ll have badge ribbons for Language Summit participants, which we’ll hand out at the summit room in the morning. As with last year, we’re using Google Forms to collect signups. The form will let you request an invitation to the summit and optionally propose a talk. Signups are open now, and will remain open until Wednesday April 12th, 2017. You can find the link to the signup form from the summit’s official web page, here: https://us.pycon.org/2017/events/language-summit/ But never forget: you don’t need to be registered for PyCon in order to attend the summit! One final note. We’re re-inviting Jake Edge from Linux Weekly News to attend the summit and provide press coverage. Jake’s done a phenomenal job of covering the previous two years’ summits, providing valuable information not just for summit attendees, but also for the Python community at large. Jake’s coverage goes a long way toward demystifying the summit, while remaining respectful of confidential information that’s deemed “off the record” ahead of time by participants. We hope to see you at the summit! [BL]arry

1 0

GitHub now visibly calls out first-time contributors
by Brett Cannon 25 Mar '17

25 Mar '17

https://twitter.com/benbalter/status/845305265159376896 Basically all of us will get to see when someone is a first-time contributor (it's not publicly visible, only to people who can merge PRs). I suspect that will not only lead to some of us being extra hands-on and forgiving of mistakes, but maybe even try to make a decision about the PR faster so they are not left wondering the fate of the PR.

1 0

4 weeks with the new workflow: what needs changing?
by Brett Cannon 24 Mar '17

24 Mar '17

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) - 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) - 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) - 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) 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? :)

18 54

[RELEASE] Python 3.6.1 is now available
by Ned Deily 22 Mar '17

22 Mar '17

On behalf of the Python development community and the Python 3.6 release team, I would like to announce the availability of Python 3.6.1, the first maintenance release of Python 3.6. 3.6.0 was released on 2016-12-22 to great interest and now, three months later, we are providing the first set of bugfixes and documentation updates for it. Although it should be transparent to users of Python, 3.6.1 is the first release after some major changes to our development process so we ask users who build Python from source to be on the lookout for any unexpected differences. Please see "What’s New In Python 3.6" for more information: https://docs.python.org/3.6/whatsnew/3.6.html You can find Python 3.6.1 here: https://www.python.org/downloads/release/python-361/ and its change log here: https://docs.python.org/3.6/whatsnew/changelog.html#python-3-6-1 The next maintenance release of Python 3.6 is expected to follow in about 3 months by the end of 2017-06. More information about the 3.6 release schedule can be found here: https://www.python.org/dev/peps/pep-0494/ -- Ned Deily nad(a)python.org -- []

1 0

Broken Travis blocks merging
by Serhiy Storchaka 19 Mar '17

19 Mar '17

For now all Travis CI builds failed. This blocks merging new PRs, backports and old PRs that need resolving Misc/NEWS conflicts. For details see https://github.com/python/core-workflow/issues/54 .

2 1

cherry_picker.py is now in core-workflow repo
by Mariatta Wijaya 16 Mar '17

16 Mar '17

Hi, I imported my cherry picker script into https://github.com/ python/core-workflow/tree/master/cherry_picker/ Please try it out if you need to do backports for CPython. It still needs some improvement with handling merge conflict, but if you don't anticipate any conflict then it should make things easy for you. (things that do not involve Misc/NEWS, for example) After the migration, I used it to cherry-pick this PR: https://github.com/python/cpython/pull/670 can confirm it works. Thanks Nick Coghlan who has started using and contributing to it too :) I believe he has a PR coming soon that adds a --dry-run option, which I look forward to :) Mariatta Wijaya

1 0

Recent updates to "make patchcheck"
by Nick Coghlan 12 Mar '17

12 Mar '17

Hi folks, I use "make patchcheck" a fair bit as a checklist for whether or not a change needs any further adjustments before merging, but found it's patch-based approach less then helpful with the new PR-centric workflow. Accordingly, I just merged a few key updates to master and the 2.7/3.5/3.6 branches: - it will automatically determine the current base branch, and check all files changed relatively to that branch, rather than only checking uncommitted changes - it accepts any ".git" entry as indicating a checkout (nor just directories), since "git worktree" defines ".git" as a configuration file The automatic determination of the base branch is as follows: - if an "upstream" remote is defined, it's used as the base branch remote, otherwise "origin" is used - if sys.version_info.releaselevel is "alpha", the base branch is "<remote>/master" - otherwise it is "<remote>/X.Y" (also based on sys.version_info) Note that this works fine for "make patchcheck" (since it uses the just built Python to run Tools/scripts/patchcheck.py), but anyone running the tool directly rather than through the makefile may have to adjust how they do things. Cheers, Nick. -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia

1 0