Mailman 3 October 2017 - python-committers

GitHub: remove the "needs backport to 3.5" label?
by Victor Stinner Aug. 20, 2019

Aug. 20, 2019

Hi, Python 3.5 entered security fix only mode. Should we now remove the "needs backport to 3.5" label? Other security only branches don't have this label neither (3.3 and 3.4). Victor

6 11

Travis stuck forever with "Waiting for status to be reported"
by Xavier de Gaye Oct. 23, 2017

Oct. 23, 2017

This has happened to me at least twice. FWIW closing the PR and re-opening it triggers a new sequence of checks and fixes the problem. Xavier

1 0

Merging a PR with failed CI
by Antoine Pitrou Oct. 22, 2017

Oct. 22, 2017

Hello, What is the recommended way of merging a PR when Travis-CI failed for unrelated reasons? (apparently an external NNTP server is having hiccups) See https://github.com/python/cpython/pull/4065 Regards Antoine.

2 1

[RELEASE] Python 3.7.0a2 is now available for testing
by Ned Deily Oct. 17, 2017

Oct. 17, 2017

Python 3.7.0a2 is the second of four planned alpha previews of Python 3.7, the next feature release of Python. During the alpha phase, Python 3.7 remains under heavy development: additional features will be added and existing features may be modified or deleted. Please keep in mind that this is a preview release and its use is not recommended for production environments. The next preview, 3.7.0a3, is planned for 2017-11-27. You can find Python 3.7.0a2 and more information here: https://www.python.org/downloads/release/python-370a2/ -- Ned Deily nad(a)python.org -- []

1 0

OK to back-fill "awaiting" labels on open issues?
by Brett Cannon Oct. 10, 2017

Oct. 10, 2017

I noticed today that out of about 19 pages of issues, only the first 5 have "awaiting" labels. Would people object if I back-filled those open issues lacking an "awaiting" label? For those that have a "changes requested" review a comment that said roughly "we noticed there's a review asking for changes; if you already did that then let us know by saying 'I didn't expect the Spanish Inquisition' and we will update this pull request accordingly" (the other stages don't have potential false-positives). The reason I'm asking before coding this up and running it is there will be some churn in notifications for those issues that get a comment about "awaiting changes".

4 7

Requesting reviews
by Paul Moore Oct. 6, 2017

Oct. 6, 2017

I'm seeing a lot of review requests from github, asking for reviews from the Windows team. Many of the PRs don't as far as I can see have much Windows-specific about them. It doesn't bother me too much (I just ignore ones I don't have anything to say on) but I thought the idea of having the teams was to ask for specific experts to take a look when needed? As I say, it's not a big deal for me, but I'm curious how others think the review teams should be used. Paul

5 7

What is a CPython core developer?
by Victor Stinner Oct. 4, 2017

Oct. 4, 2017

Hi, Recently, I asked their opinion to a few core developers about promoting some active contributors to core developers. It seems like we have no clear rules to decide if a contributor can be promoted or not. The problem is that sometimes, I am explicitly asked: What are the steps to become a core developer? Well, I'm not sure why some people really want to become core developers, but that's not question here :-) I started to list "responsabilities" (is it the correct word?) of a core developer. First of all, I like how Mariatta summarized a promotion (in an oral discussion that we had). Becoming a core developer doesn't give *power*, but *responsabilities*. (Sorry, I'm not sure about the exact wording, maybe Mariatta can correct me here ;-)) I also see that some core developers are more conservative, want to reduce the risk of regressions, while some others are more on the "forgiveness" trend ("it's better to ask forgiveness than permission"). I think that it's perfectly normal and expected to have people on the two sides. The question is how to find a compromise in the middle. I identified the following CPython core developers responsabilities: * Long term commitement. We someone lands a big chunk of code, we need someone to maintain it for at least the next 2 years. Maybe for the next 10 years. I think that some people sign with their blood to maintain crappy code for their own life, but it's better to not elaborate this part ;-) * Review patches and pull requests. While we don't require not expect newcomers to review, we expect that core developers dedicate a part of their time on reviews. * Know the CPython workflow. Be aware of the pre-commit and post-commits CIs. How ideas are discussed. It's not only about writing and pushing patches. * For C developer: know CPython specific issues like reference leaks and the garbage collector. We expect that a core developer write code with no reference leak, right? ;-) * Good quality patches: proposed changes are good (or almost good) at the first iteration. I'm not sure about this point, but I know a few other developers have this requiurement to promote someone. * Pushing core means becoming responsible for this code. For regressions, backward compatibility, security, etc. * Something else? I don't expect this list to be complete. A vote for a promotion is always done on a case by case basis, mostly because it's really hard to be ready on *all* expected points. The discussion is more to estimate how far is the contributor in its learning, if it's enough, if more learning is needed, or if mentoring is needed. Maybe we should also formalize the mentoring for contributors identified as potential core developers. It can be an explicit step in the promotion process. Each last core developers who get promoted last year get a mentor if I recall correctly. What do you think? I started to write an article "What is a CPython core developer?" which describes even more things: https://cpython-core-tutorial.readthedocs.io/en/latest/what_is_a_cpython_co… Victor

8 9

Hacktoberfest
by Mariatta Wijaya Oct. 4, 2017

Oct. 4, 2017

Hi, October is hacktoberfest (https://hacktoberfest.digitalocean.com/) In the month of October, people can sign up and contribute to open source projects on GitHub. If they make 4 PRs during Hacktoberfest, they'll earn a limited edition T-Shirt. If it's ok with everyone, I want to create "hacktoberfest" label and apply it to some of the open issues in the DevGuide and core-workflow repo. The purpose of the label is to make the repo discoverable, so it shows up as one of the participating projects: https://github.com/search?q=label%3Ahacktoberfest+state%3Aopen+type%3Aissue… Mariatta Wijaya

6 7

Minor followup to the pynvm discussion
by R. David Murray Oct. 3, 2017

Oct. 3, 2017

A link to a possibly-interesting-in-this-context project was just posted to the pmem mailing list: https://arrow.apache.org/ This is a standard for communicating data structures between processes with zero-copy semantics, and is backed by the person who created Python Pandas. I thought Davin in particular might find this interesting if he isn't already aware of it. --David

1 0

[RELEASE] Python 3.6.3 is now available
by Ned Deily Oct. 3, 2017

Oct. 3, 2017

On behalf of the Python development community and the Python 3.6 release team, I am happy to announce the availability of Python 3.6.3, the third maintenance release of Python 3.6. Detailed information about the changes made in 3.6.3 can be found in the change log here: https://docs.python.org/3.6/whatsnew/changelog.html#python-3-6-3-final Please see "What’s New In Python 3.6" for more information about the new features in Python 3.6: https://docs.python.org/3.6/whatsnew/3.6.html You can download Python 3.6.3 here: https://www.python.org/downloads/release/python-363/ The next maintenance release of Python 3.6 is expected to follow in about 3 months, around the end of 2017-12. More information about the 3.6 release schedule can be found here: https://www.python.org/dev/peps/pep-0494/ Enjoy! -- Ned Deily nad(a)python.org -- []

1 0