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
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
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
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 -- []
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
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
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~
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
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!
