python-committers April 2018

python-committers@python.org

18 participants
12 discussions

GitHub: remove the "needs backport to 3.5" label?
by Victor Stinner 20 Aug '19

20 Aug '19

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

Licences for PyCharm and other JetBrains products
by Vinay Sajip 17 Dec '18

17 Dec '18

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 1

Idea: Create subteams?
by Victor Stinner 15 May '18

15 May '18

Hi, While thinking about how to get more contributors onboard, I identified that one bottleneck is building trust. Currently, a vote to promote a contributor as a core dev requires the approval of almost all active core developers, and this list is quite large (50 people? more?). It takes a lot of time until a contributor is known by enough people to start the process to promote them as a core dev. My idea is to create subteams which would have less permission than "everything": restrict changes to specific directories. It seems like in practice, we already have such subteams: Documentation, IDLE and asyncio have a dedicated Component in the bug tracker, their own directories, a group of people focused on these components, and even... a dedicated mailing list! The restriction would be the ability to merge a pull request. Since miss-ilington recently got the power of merging a PR, it makes me think that it's doable to allow "non core" people to merge a change under certain conditions. For example, let's say that a contributor called "Alice" is part of a subteam. If Alice approves a change in the review, added the "approved" label and the CI pass: a bot can merge the change, since Alice is allowed to merge a PR modifying specific directories.If Alice doesn't have the power, the bot may notice Alice that she lacks permission and the bot may remove the label. IMHO it's better to have two steps to merge: approval in the review and a label, sometimes a change looks good but should not be merged yet, or you don't want to take the responsibility to merge it yourself. What about current core developers? No change for them, they keep their "super power" to modify everything. If a member of a subteam shows interest to do more than only working in a subteam, the usual promotion process with a vote on python-committers can be followed. My expectation is that it will be faster to promote a contributor into a subteam. It's easier to trust someone if they is only allowed to modify some directories. In my experience, people with the same interest find their way to meet other people working on the same topic. The trust is built naturally in a component. You may see a parallel with the Linux kernel hierarchy and Linux subsystems, but the proposed organization is different. In Python, the tradition is that everybody works in the same repository. I don't want to change that. What do you think? Do you like the idea of subteams? Is it feasible (the label and the bot things)? I identified 3 obvious subteams: * Documentation * IDLE * asyncio Maybe you see more candidates? Victor

4 4

Orphaned backports
by Serhiy Storchaka 14 May '18

14 May '18

miss-islington is an awesome bot! It makes fixing bugs in multiple versions much simpler. You need just accept automatically created backporting PRs. But there is a downside. miss-islington makes the life so easier, that sometimes you forgot about not finished backports. miss-islington can fail to backport some changes for different reasons. Currently on GitHub there are tens merged PRs labeled for backporting, but backports were not finished. Please take attention if your PRs in one of the following lists: https://github.com/python/cpython/pulls?q=label%3A%22needs+backport+to+3.7%… https://github.com/python/cpython/pulls?q=label%3A%22needs+backport+to+3.6%… https://github.com/python/cpython/pulls?q=label%3A%22needs+backport+to+2.7%…

4 7

IMPORTANT - final 3.7.0 beta cutoff!
by Ned Deily 30 Apr '18

30 Apr '18

Just a reminder that 3.7.0b4 is almost upon us. Please get your feature fixes, bug fixes, and documentation updates in before 2018-04-30 ~23:59 Anywhere on Earth (UTC-12:00). That's about 16 hours from now. IMPORTANT: We are now in the final phase of 3.7.0. Tomorrow's 3.7.0b4 is the final beta planned for 3.7.0. After tomorrow, the next planned release is the 3.7.0 release candidate, on 2018-05-21, for final testing. Our goal is to have no changes between the release candidate and final; after rc1, changes applied to the 3.7 branch will be released in 3.7.1. Between now and the rc1 cutoff, please double-check that there are no critical problems outstanding and that documentation for new features in 3.7 is complete (including NEWS and What's New items), and that 3.7 is getting exposure and tested with our various platorms and third-party distributions and applications. Also, during the time leading up to the release candidate, we will be completing the What's New in 3.7 document. As noted before, the ABI for 3.7.0 was frozen as of 3.7.0b3. You should now be treating the 3.7 branch as if it were already released and in maintenance mode. That means you should only push the kinds of changes that are appropriate for a maintenance release: non-ABI-changing bug and feature fixes and documentation updates. If you find a problem that requires an ABI-altering or other significant user-facing change (for example, something likely to introduce an incompatibility with existing users' code or require rebuilding of user extension modules), please make sure to set the b.p.o issue to "release blocker" priority and describe there why you feel the change is necessary. If you are reviewing PRs for 3.7 (and please do!), be on the lookout for and flag potential incompatibilities (we've all made them). Thanks again for all of your hard work towards making 3.7.0 yet another great release - coming to a website near you on 06-15! --Ned -- Ned Deily nad(a)python.org -- []

1 0

How to calm down the discussion on the PEP 572?
by Victor Stinner 26 Apr '18

26 Apr '18

Hi, Since 2 or 3 years, I saw that that discussions on some PEPs get more and more emails every year. Maybe because Python became more popular? Openness is a Python quality, but shortly, the amount of emails becomes an issue, at least for the author of the PEP. I counted the number of emails per day of the python-dev mailing list, using mbox archives available at: https://mail.python.org/pipermail/python-dev/ My script: https://github.com/vstinner/misc/blob/master/python/parse_mailman_mbox.py In March, python-dev got 246 emails with a maximum of 31 the 2018-03-21. In April, the traffic was between 3 and 27 emails per day until the start of the chaos: ... 2018-04-17: 27 2018-04-18: 20 2018-04-19: 11 2018-04-20: 36 2018-04-21: 36 2018-04-22: 31 2018-04-23: 32 2018-04-24: 72 2018-04-25: 76 2018-04-26: 23 2018-04-27: 10 Current maximum: 76 emails received at 2018-04-25!? I'm not sure that it's still possible to read carefully all emails to python-dev and write constructive replies. It seems like people are answering immediately, without reading past emails nor reading other emails sent the same day. I'm also concerned by the general mood of the discussion. Are we still discussing arguments in polite way? How can we calm down the discussion, and ask people to don't reply immediately but instead try to listen to the other people? IHMO everybody had enough time to give their very important opinion (I wrote my own very important opinion, don't worry!) on python-ideas and then on python-dev. We are now turning around. Can we give Chris more time to update his PEP? In my experience, the PEP is the most constructive tool to drive a discussion. I chose to write to python-committers because I now fear that I would get too many replies on python-dev ... Victor

4 6

Welcoming Petr Viktorin as our newest core developer :)
by Nick Coghlan 24 Apr '18

24 Apr '18

Hi folks, With my recent proposal to accept Petr Viktorin as a specialist core developer focusing on extension module imports receiving several +1's and no concerns being raised, I'm happy to report that Brett has now granted Petr his additional access on GitHub, the issue tracker, and this mailing list. Welcome, Petr! :) Cheers, Nick. P.S. When adjusting the nosy list on the issue tracker, you'll find there's also a new "extension modules" topic, which can be selected to subscribe both Petr and I to the issue :) -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia

8 7

missing email thread [was: Welcoming Petr ...]
by Ethan Furman 23 Apr '18

23 Apr '18

On 04/23/2018 09:37 AM, Christian Heimes wrote:> On 2018-04-23 17:43, Ethan Furman wrote: >> On 04/23/2018 07:39 AM, Nick Coghlan wrote: >>> With my recent proposal to accept Petr Viktorin as a specialist core >>> developer focusing on extension module imports receiving several +1's >>> and no concerns being raised, >> >> Where did this conversation take place? I see no record of it here nor >> on the Zulip Chat channels. > > We discussed the matter 10 days ago on this very mailing list, > https://mail.python.org/pipermail/python-committers/2018-April/005276.html Huh. I keep 30 days worth of email for Python-Committers but I don't have that thread. If anybody has any ideas on what might have happened I'd love to hear them! I use Thunderbird on Ubuntu 12. (I'm pretty sure I didn't delete the thread. ;) ) -- ~Ethan~

1 0

Proposing Petr Viktorin as a specialist core developer
by Nick Coghlan 14 Apr '18

14 Apr '18

Hi folks, I'd like to propose Petr Viktorin as a specialist core developer, focusing on extension module imports. Petr was the primary designer & implementer for the accepted PEP 489 multi-phase extension module initialisation PEP, and has continued to work on changes related to that while mentoring Marcel Plch in the development of PEP 547 (which will get extension modules to the point where they can even support execution with the -m switch). When an import system issue specifically related to extension modules gets brought to my attention, I'll typically add Petr to the nosy list to request his opinion. Regards, Nick. P.S. While bringing on another extension module import system maintainer is my primary motivation for nominating him, I'll also note that Petr's also long been my primary point of contact for advice on CPython integration into Fedora, RHEL, and CentOS (he's the current Python maintenance team lead at Red Hat), and he also has a lot of practical Python 2->3 porting experience (as a result of coordinating much of the migration effort for Fedora and RHEL, including leading the creation of https://portingguide.readthedocs.io/en/latest/index.html ) -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia

9 8

Experimenting with a Zulip instance for Python core development
by Brett Cannon 13 Apr '18

13 Apr '18

Over on core-workflow we decided to try out Zulip as a "more hyper-interactive email" way to communicate (at least that's how Guido phrased it :) . We have set up https://python.zulipchat.com/ for *just* Python core development discussion (i.e. this is not for general Python support). People so far seem to be enjoying it and so I'm ready to open it up to a bit more by announcing it here (and if this goes well then I will announce on python-dev). Now this is just an experiment and we still expect any important decisions that need to be discussed with everyone to happen here or on python-dev (e.g. see INADA-san's recent email about PyUnicode field deprecations which started over on Zulip but was brought over to email for wider discussion). This is also not officially part of the Python core team's communication channels like this mailing list, python-dev, or #python-dev is. But if this experiment does work out well then we will discuss over on core-workflow (and on Zulip ;) about making this more official. Do note that the instance is rather open so you can create new streams and add bots as desired. We already have bots set up for all commits, build failures, and deployments of Bedevere and the Knights Who Say Ni (Mariatta will probably set up Miss Islington when she gets back from her break). Anyway, feel free to log in and give it a try!

1 0

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

python-committers April 2018