python-committers January 2018

python-committers@python.org

31 participants
24 discussions

trivial tag on GitHub?
by Ethan Furman 27 Jan '18

27 Jan '18

I created a new pull request to add a forgotten news entry, and now it's going through all the pre-checks, etc. I seem to recall we could add a "trivial" tag to an issue to skip those. Is that still true, and if so, how? -- ~Ethan~

5 7

Let's give commit privileges to Nathaniel J. Smith
by Yury Selivanov 25 Jan '18

25 Jan '18

Hi, I want to propose granting commit privileges to Nathaniel J. Smith. He's interested in the idea of becoming a core developer, and given the quality of his contributionsI think he won't need any extensive mentoring (although I'll be happy to assist Nathaniel in the beginning). Nathaniel has been a prolific PEP author: * Single-authored: PEP 465 Matrix Multiplication (accepted), PEP 521, PEP 533, PEP 568; * Co-authored: PEP 513 (active), PEP 516, PEP 517 (accepted), PEP 518 (accepted), PEP 522. * Many PEPs mention his name in acknowledgements. He also has a few sufficiently complex patches committed, some of which touch complex areas like ceval loop and signals handling: * bpo-32591: Add native coroutine origin tracking * bpo-30579: Allow TracebackType creation and tb_next mutation from Python * bpo-30050: Allow disabling full buffer warnings in signal.set_wakeup_fd * bpo-30039: Don't run signal handlers while resuming a yield from stack * bpo-30038: fix race condition in signal delivery + wakeup fd * etc He's been very active on python-dev, python-ideas, bugs.python.org and github. Here's an example where Nathaniel's research helped us to make a right decision to fix a broken socket object API: https://bugs.python.org/msg308450. He helped me quite a bit with the design of PEP 550 and PEP 567, and he's doing some interesting work in the async/await area. So... let's make it happen? :) Yury

16 16

Requirements to get the "bug triage" permission?
by Victor Stinner 25 Jan '18

25 Jan '18

Hi, I identified some active contributors and I would like to offer them to get the "bug triage" permission. What's the requirements to give such permissions to someone? On my "Different stages of core developers" "lader", it's the 3rd stage ("step"?): http://cpython-core-tutorial.readthedocs.io/en/latest/what_is_a_cpython_cor… Requirements to become a core developer (get the "commit bit") are now written down: http://cpython-core-tutorial.readthedocs.io/en/latest/what_is_a_cpython_cor… It would be nice to write down requirements to get the bug triage permission. IMHO the requirements are quite low: * at least one commit merged in Python * signed the CLA * be nice and respectful * don't close a bug if it's not well understood to not "loose" information (closed bugs are ignored in search by default, and hidden from the main page). Did it happen in the past that we removed the bug triage permission to someone who abused this power? Maybe we can give some guide lines on how to behave on the bug tracker? Responsability for bug tracker: * Request more information if a report is incomplete * Ping original reporters if they don't reply * Adjust Python version, component, bug type, etc. * Rewrite the issue title if needed * Close duplicated bugs as DUPLICATE * Close irrevelant bugs as NOTABUG The exact behaviour on the bug tracker is not specified. For example, when someone asks for help on code, I close the issue and suggest to use a different forum to get help, without giving examples of forums (since I simply don't know them :-)). When the reported issue described a legit Python behaviour, I try to explain the rationale of the behaviour before closing the issue as "not a bug". Sometimes I'm just tired of the 4th bug report on "floating point rouding issue" and just give the link to the FAQ without explaining anything. Devguide §Helping Triage Issues https://devguide.python.org/tracker/#helptriage Victor

9 21

Mentoring and promoting contributors (was: Let's give commit privileges to Nathaniel J. Smith)
by Victor Stinner 25 Jan '18

25 Jan '18

Hi, 2018-01-25 0:29 GMT+01:00 Eric V. Smith <eric(a)trueblade.com>: > +1. I actually thought [Nathaniel Smith] was a committer already. By the way, if you notice an active contributor is good candidate to become a core dev in the long term, you may start the process that I described here: https://github.com/vstinner/misc/blob/master/cpython/pep-core_dev_process.r… My proposed process is made of small steps to build a trust relationship and to train contributors until they produce "commit-ready change". For you, the main requirement is time, be available to review changes and answers to questions by email :-) Last weeks, I looked at contributors who got the most commits merged into master in the last 6 months. That's how I selected Cheryl Sabella, Sanyam Khurana and Pablo Galindo Salgado. I also asked two contributors if they would like to become core, but they declined my offer. I added a new section in my process document: § "Becoming A Core Developer Is Not a Goal". I'm not sure that it's the best title ever. """ CPython isn't the easiest place to start. The development process is rather enterprisy with long release cycles (release every 18 months) and rigid backwards compatibility policy. CPython also support many different platforms and CPU architectures. Are you sure that CPython itself is the best project for you? Depending on your interests and skills, you may enjoy better to contribute to another Python project with lower backward compatibility constraints and a faster release cycle. Being a CPython core developer involves responsibilities and usually requires a lot of time. Long-term commitment is also a major expectation, even if it's not a strict requirement. Becoming a core developer should not be seen as a recognition of a contributor work, but more as a constraint :-) Merging a change implies becoming responsible regressions, backward compatibility, security, etc. of this code. It is perfectly fine to contribute to CPython without being a core developer. In most cases, not being able to merge your own work is not a blocker issue. """ I'm not sure about this sentence: "Becoming a core developer should not be seen as a recognition of a contributor work, but more as a constraint :-)". My intent is to discourage people who "want to become a core dev" for the bad reasons (to become famous? I don't know exactly) without understanding the expected responsibilities. Victor

1 0

Python workflow quirks with mercurial and hg-git extension
by Jesus Cea 25 Jan '18

25 Jan '18

I plan to come back to python development (about time!) but I truly hates git. I am experimenting with mercurial + hg-git extension and it is quite usable (after the initial painfully slow clone time), but I am having small quirks that I would like to iron out with a fellow more experienced or also interested in this approach. Anybody out there?. If this is considered off-topic, please let me know. -- Jesús Cea Avión _/_/ _/_/_/ _/_/_/ jcea(a)jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/ Twitter: @jcea _/_/ _/_/ _/_/_/_/_/ jabber / xmpp:jcea@jabber.org _/_/ _/_/ _/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ "My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz

3 2

[RELEASED] Python 3.4.8rc1 and Python 3.5.5rc1 are now available
by Larry Hastings 23 Jan '18

23 Jan '18

On behalf of the Python development community, I'm pleased to announce the availability of Python 3.4.8rc1 and Python 3.5.5rc1. Both Python 3.4 and 3.5 are in "security fixes only" mode. Both versions only accept security fixes, not conventional bug fixes, and both releases are source-only. You can find Python 3.4.8rc1 here: https://www.python.org/downloads/release/python-348rc1/ And you can find Python 3.5.5rc1 here: https://www.python.org/downloads/release/python-355rc1/ Happy Pythoning, //arry/

1 0

Official way to check out a tag?
by Stefan Krah 23 Jan '18

23 Jan '18

Hello, what is the official way to checkout a tag for debugging? I did: git checkout v3.6.0 This just worked in mercurial, but doing the above results in a compile error: threadmodule.c:1355: multiple definition of `PyInit__thread' Stefan Krah

3 3

Slipping Python 3.5.5rc1 and 3.4.8rc1 because of a Travis CI issue--can someone make Travis CI happy?
by Larry Hastings 23 Jan '18

23 Jan '18

I have three PRs for Python 3.5.5rc1: https://github.com/python/cpython/pull/4656 https://github.com/python/cpython/pull/5197 https://github.com/python/cpython/pull/5201 I can't merge them because Travis CI is unhappy. All three CI tests fail in the same way, reporting this error: The command "pyenv global system 3.5" failed and exited with 1 during . Since Travis CI is a "required check", Github won't let me merge the PR. Yes I could manually merge the patches by hand but I'm hoping it doesn't come to that. I'm slipping 3.4.8rc1 because I prefer to do both releases at once. I'm hoping this problem will be resolved quickly; if we only slip the RCs by a day or two I won't slip the final releases (in about two weeks). PLS SND HALP, //arry/

4 4

Pablo Galindo Salgado got bug triage permission, mentored by Victor
by Victor Stinner 18 Jan '18

18 Jan '18

Hi, To recognize the good contributions of Pablo Galindo Salgado, I gave him the bug triage permission on bugs.python.org. Pablo already got 8 commits merged into master since September 2017. He is working on non-trivial topics like designing an API to expose posix_spawn() in the os module: https://mail.python.org/pipermail/python-dev/2018-January/151661.html He also fixed a timeout rounding issue, for example: https://github.com/python/cpython/commit/59af94fa61bf90adbe624508e909b5d6ef… I will mentor Pablo during 1 month as explained in my proposed process: https://github.com/vstinner/misc/blob/master/cpython/pep-core_dev_process.r… Congrats Pablo! Note: I added Pablo in CC of this email. Victor

1 0

Current Travis CI "job backlog incident"
by Victor Stinner 17 Jan '18

17 Jan '18

Hi, FYI Travis CI is sick tonight: https://www.traviscistatus.com/ Jan 17, 00:26 UTC : Update - We are still investigating the job backlog incident. Victor

1 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

python-committers January 2018