python-committers June 2018

python-committers@python.org

32 participants
28 discussions

GitHub: remove the "needs backport to 3.5" label?

by Victor Stinner

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

1 year, 11 months

Licences for PyCharm and other JetBrains products

by Vinay Sajip

Recently I received 20 one-year licenses from JetBrains for the PyCharm IDE (Professional) and other JetBrains products (the licenses cover their "All Products Pack") for use in Python development. There are 11 licenses available - of the licenses I asked for last year, nine people took them up, so those are in use and come out of the allocation of 20. Those of you who took up the licences last time should find that the tools continue to work normally. The licences expire on 27 November 2018. If any others of you are interested in using these licenses, let me know off-list and I will forward the license access details to you. To access the licenses, you will need to have (or create) a JetBrains account. Regards, Vinay Sajip

2 years, 7 months

Results of Pablo's promotion votes: Pablo is promoted as a core dev!

by Victor Stinner

Hi, The result of the vote to to promote Pablo Salingo Salgado as core developer after one week is positive: I declare that Pablo is now a core developer, congrats! I will follow the usual process to actually make him a core dev, and ask him to write a short introduction email to this list. But I also noted that Pablo lacks experience to be fully autonomous on merging pull requests, so I also requires that Pablo will have to be strictly mentored by me for 3 months. By strict, I mean that Pablo will have to ask me to merge any pull request. This strict mentoring may be extended depending on Pablo's progress. As Eric Snow wrote, I vouch for Pablo: don't hesitate to blame me directly if anything goes wrong :-) Giving more responsibilities to Pablo is part of the learning process. Reviewing as a core developer is different than a review as a contributor: core developers are expected to actually merge a pull request once they approve the change. Merging a pull request is a big responsibility and an investment in the long-term, because the committer is expected to fix regressions and issues related to this change for next months, if not next years. Note: Cheryl Sabella has also been identified as an active contributor who may be promoted as well. I am already discussing with her about that for 1 month, but last month, Cheryl chose to wait. I will keep you in touch ;-) Vote results. Promote (+1): 8 votes * Victor Stinner * Terry Reedy * Carol Willing * Gregory P. Smith ("+0.5") * Eric Snow * Brett Cannon * Nathaniel Smith * Antoine Pitrou ("+0.5") Wait (-1): 1 vote * Berker Peksağ Neutral (0): 1 vote * Serhiy Storchaka ("-0") Victor

2 years, 12 months

Mentoring Office Hours - the idea, and a question

by Brian Curtin

Hey all, At the Language Summit last week, after Mariatta's talk we had a conversation around diversity and how to grow our contributor base, which led to someone (Steve Dower?) suggesting we post a sort of "Office Hours" list. This would be a list of current core developers who are interested in being available at set time(s) for helping mentor newer contributors in our community through our process and, if they're interested, mentoring them through the process of becoming core developers themselves. This "Office Hours" concept is a type of thing that has worked well elsewhere, including around the software world, and we have some people interested in offering said mentorship, so I would like to move on to getting this list up somewhere so we can start doing it. With that said, before I go make a PR to the devguide to start iterating on the implementation, an important question: As this is both an event similar to an in-person meetup and an event meant to be a safe space for those getting started, it will explicitly mention the code of conduct. As such, it needs a person/persons/list to contact should something arise in this context that needs to be handled. What/who should that be? * Suggestion 1: use the already in-place core-mentorship-owner(a)python.org, though I can't tell who's on there. * Suggestion 2: Create some new list with a few key people on it. * Suggestion 3: List some direct names. Who? As for implementation, there are some tools out there we could possibly use, but in the interests of getting something out there I'm just going to make a table and fill in some common information, starting with my own. Calendar apps and other integrations can come as we figure them out. Brian

3 years

A different way to focus discussions

by Guido van Rossum

Discussing PEPs on python-dev and python-ideas is clearly not scalable any more. (Even python-committers probably doesn't scale too well. :-) I wonder if it would make sense to require that for each PEP a new GitHub *repo* be created whose contents would just be a draft PEP and whose issue tracker and PR manager would be used to debate the PEP and propose specific changes. This way the discussion is still public: when the PEP-specific repo is created the author(s) can notify python-ideas, and when they are closer to submitting they can notify python-dev, but the discussion doesn't attract uninformed outsiders as much as python-{dev,ideas} discussions do, and it's much easier for outsiders who want to learn more about the proposal to find all relevant discussion. PEP authors may also choose to use a different repo hosting site, e.g. Bitbucket or GitLab. We can provide a script that allows checking the formatting of the PEP easily (basically pep2html.py from the peps repo). Using a separate repo per PEP has the advantage that people interested in a topic can subscribe to all traffic in that repo -- if we were to use the tracker of the peps repo you would have to subscribe to all peps traffic. Thoughts? (We can dogfood this proposal too, if there's interest. :-) -- --Guido van Rossum (python.org/~guido)

3 years

Vote to promote Pablo Salingo Salgado as core developer

by Victor Stinner

Hi, I propose to promote Pablo Salingo Salgado as a core developer and so open a vote during one week. If there is no strong opposition, I will promote him but also continue to mentor him for a least one month. Pablo is contributing frequently to Python since almost one year. He added os.preadv()/pwritev() to Python 3.7 and os.posix_spawn() to Python 3.8. I am now waiting for his os.copy_file_range() function! (Others are working on it.) https://bugs.python.org/issue26826 I am mentoring Pablo Salingo Salgado since January. I am watching his hard work since last September. He made many non trivial and useful contributions to Python. I think that he understands well how Python is developed, is respectful, try to find answers alone before asking, and is eager to learn. In case of doubt, he ask others before doing something, like closing an issue. I trust that Pablo will respect opinions of others, like not merging a PR if someone disagree. Pablo's merged PR: https://github.com/python/cpython/pulls?utf8=%E2%9C%93&q=is%3Aclosed+is%3Ap… He got 22 commits merged into master between September 2017 and June 2018. If Pablo is promoted as a core developer, I propose to continue to be his mentor for at least one month, and ask him before merging any PR. Note: Pablo already has the bug triage permission for 5 months: https://mail.python.org/pipermail/python-committers/2018-January/005133.html Victor

3 years

Python 3.7.0 is now available! (and so is 3.6.6)

by Ned Deily

On behalf of the Python development community and the Python 3.7 release team, we are pleased to announce the availability of Python 3.7.0. Python 3.7.0 is the newest feature release of the Python language, and it contains many new features and optimizations. You can find Python 3.7.0 here: https://www.python.org/downloads/release/python-370/ Most third-party distributors of Python should be making 3.7.0 packages available soon. See the "What’s New In Python 3.7" document (https://docs.python.org/3.7/whatsnew/3.7.html) for more information about features included in the 3.7 series. Detailed information about the changes made in 3.7.0 can be found in its change log. Maintenance releases for the 3.7 series will follow at regular intervals starting in July of 2018. We hope you enjoy Python 3.7! P.S. We are also happy to announce the availability of Python 3.6.6, the next maintenance release of Python 3.6: https://www.python.org/downloads/release/python-366/ Thanks to all of the many volunteers who help make Python Development and these releases possible! Please consider supporting our efforts by volunteering yourself or through organization contributions to the Python Software Foundation. https://www.python.org/psf/ -- Ned Deily nad(a)python.org -- []

3 years, 1 month

3.7.0 / 3.6.6 Update: all systems go for final releases!

by Ned Deily

A quick update: after many months we are at the finish line. We are on track (mixing metaphors) to release 3.7.0 (and 3.6.6) this week on 2018-06-27. Since 3.7.0rc1 shipped 2 weeks ago, I am aware of only two noteworthy regressions that have been identified and now fixed. Since the issues for both have the potential to impact some (but small) subsets of 3.7.0 users and the fixes for both are straightforward and appear to be low-risk, I am planning to cherry-pick the fixes for them into 3.7.0 final without either another release candidate cycle or waiting for 3.7.1. There may be some doc fixes that get cherry-picked as well. At the moment, there are no plans for any bug cherry-picks for 3.6.6 final. As you know, a new feature release is a big deal and something for all of us to be proud of. A new feature release also has various, mostly minor, impacts to lots of different parts of our development infrastructure: to multiple branches of the cpython repo, to documentation builds, to different parts of the python.org web site, etc. You will start to see some of the changes roll out over the next 24 to 36 hours and it may take some time until everything is in place. So please be patient until the official release announcement goes out before reporting release-related issues. Also be advised that over the same period, there may be a few brief periods where commit access to various cpython branches is blocked in order to do the necessary release engineering. If you run into this, for example when trying to merge a PR, please try again in a few hours. Thanks and more later! https://bugs.python.org/issue33851 https://bugs.python.org/issue33932 -- Ned Deily nad(a)python.org -- []

3 years, 1 month

If I backport to 3.7, it will not go into 3.7.0, correct?

by Eric V. Smith

I have a few things I want to fix in 3.7.1, but don't need to be 3.7.0. I can backport those to the 3.7 branch now, correct? Reading Ned's message I wasn't exactly sure of the timing and don't want to screw things up. I assume he's keeping a private branch for 3.7.0. Eric

3 years, 1 month

Introduction - Pablo Galindo Salgado

by Pablo Galindo Salgado

Hi everyone, I would like to thank everyone for giving me their trust and allow me to be part of the team. Is really an honor to be part of such an outstanding family! I will put work and commitment in all areas of CPython maintenance and development and I will help as much as I can other core devs, contributors and everyone in the community. I will do so with extra care so nobody will be disappointed for this decision. I will fight as well to help making the Python community as inclusive and diverse as possible for everyone. Also, I will happily continue to work with Victor making sure the buildbots are happy and green. As a final note, I would like to thank Victor for his trust, encouragement and kindness, for all the time mentoring me and for vouching for me in this process. Thank you everyone for you support and for your work improving Python and the Python community! Regards from cloudy London, Pablo

3 years, 1 month

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

python-committers June 2018