Mailman 3 আগস্ট 2018 - python-committers

GitHub: remove the "needs backport to 3.5" label?
by Victor Stinner 20 আগস্ট, 2019

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

Licences for PyCharm and other JetBrains products
by Vinay Sajip 17 ডিসেম্বর, 2018

17 ডিসেম্বর, 2018

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

Winding down 3.4
by Larry Hastings 21 আগস্ট, 2018

21 আগস্ট, 2018

We of the core dev community commit to supporting Python releases for five years. Releases get eighteen months of active bug fixes, followed by three and a half years of security fixes. Python 3.4 turns 5 next March--at which point we'll stop supporting it, and I'll retire as 3.4 release manager. My plan is to make one final release on or around its fifth birthday containing the last round of security fixes. That's about seven months from now. Nothing has been merged since the releases of 3.4.9 and 3.5.6 last week, and there are no open PRs against either of those releases. But! There are still a couple languishing "critical" bugs: "shutil copy* unsafe on POSIX - they preserve setuid/setgit bits" https://bugs.python.org/issue17180 "XML vulnerabilities in Python" https://bugs.python.org/issue17239 "fflush called on pointer to potentially closed file" (Windows only) https://bugs.python.org/issue19050 It'd be nice to resolve all those issues, one way or another, before we retire 3.4. See you next March, //arry/

4 4

MSDN Subscriptions/Renewals
by Brian Curtin 20 আগস্ট, 2018

20 আগস্ট, 2018

Hey everyone, I've had a few people reach out to me recently (or not so recently; sorry about that) about renewals for their MSDN subscriptions. If yours is expired or soon to expire, please send me the email address you're using to login, your full name, and your mailing address, and after I've received a bunch of responses I'll send them over and you should get an email from Microsoft in a few days. NOTE: If you've contacted me in the last while and haven't received a response, please respond here. I'm sorry for leaving you hanging. If you've never had a subscription but would like one, please send me the email address you'll use as a login, your full name, and your mailing address. This will give you access to Microsoft's Developer Network, which includes access to things like Visual Studio and Windows licenses that we can use for working on Python. Thanks for everyone's work on Python! Brian

4 3

How to retry backport?
by Eric V. Smith 12 আগস্ট, 2018

12 আগস্ট, 2018

https://github.com/python/cpython/pull/8745 This failed (I think travis, but can't tell now). I thought I could close it and re-open it to get it to retry, but apparently not. When I closed it, the backport branch was deleted. At this stage, how do I get the backport to try again? I have spotty internet access, so it might take me a while to try this again. Thanks. Eric

3 3

Organizing an informational PEP on project governance options (was Re: Transfer of power)
by Nathaniel Smith 8 আগস্ট, 2018

8 আগস্ট, 2018

On Thu, Jul 12, 2018 at 6:35 PM, Łukasz Langa <lukasz(a)langa.pl> wrote: > I'm +1 to an Informational PEP around the state of the art in project governance. I think this is a great idea. There's a lot of experience out there on different governance models, but of course any given project only uses one of them, so knowledge about what works and what doesn't is pretty fragmented across the F/OSS community. And this is a really important decision for us and our users, so we should do due diligence. For example, we should think this through at least as carefully as we thought through Github vs. Gitlab :-). A PEP is a good format to start doing that. I volunteer to co-author such a PEP. But I'm not up to doing it on my own. So... who else wants to be a co-author? (I'm not going to pressure anyone, but Brett, Mariatta, and Carol, please know that your names were the first ones that jumped to my mind when thinking about this :-).) What I'm thinking: - While this might eventually produce some recommendations, the immediate goal would just be to collect together different options and ideas and point out their trade-offs. I'm guessing most core devs aren't interested in becoming experts on open-source governance, so the goal here would be to help the broader community get up to speed and have a more informed discussion [1]. - As per the general PEP philosophy, I think this is best done by having some amount of general discussion on python-dev/python-committers, plus a small group of coauthors (say 2-4 people) who take responsibility for filtering ideas and organizing them in a coherent document. - Places where we'll want to look for ideas: - The thread already happening on python-committers - Whatever books / articles / blog posts / etc. we can find (e.g. I know Karl Fogel's Producing OSS book has some good discussion) - Other major projects in a similar position to CPython (e.g., node.js, Rust) -- what do they do, and what parts are they happy/not-happy about? - Large Python projects (e.g. Django) -- likewise If you have suggestions for particularly interesting projects or excellent writing on the topic, then this thread would be a good place to mention them. -n [1] The NumPy project has put a lot of energy into working through governance issues over the last few years, and one thing that definitely helped was coming up with some "assigned reading" ahead of the main sprint where we talked about this. NumPy's problems are/were pretty different from CPython's, but I'm imagining this PEP as filling a similar role. -- Nathaniel J. Smith -- https://vorpus.org

8 9

Push rights for new Jython contributors
by fwierzbicki＠gmail.com 7 আগস্ট, 2018

7 আগস্ট, 2018

It's been a while since we added a Jython contributor, so I no longer know what the process would be and we have at least one person we'd like to add. Previously, I think the process was: 1) Contributor creates a user on bugs.python.org using their real name. 2) Contributor signs the PSF agreement (not the Jython-specific one, which is not used anymore). 3) Someone gives contributor push rights to hg.python.org. Is this still the process for Jython? Kind regards, Frank Wierzbicki

2 1

Reminder of BDFL succession timeline + CFP
by Mariatta Wijaya 5 আগস্ট, 2018

5 আগস্ট, 2018

Since this is like a CFP I figured we should clarify what's expected the proposal, and I also wanted to be more detailed in the timeline. *Oct 1 00:00:00 UTC:* Deadline of coming up with proposals of governance model. To be included in the proposal: - explanation and reasoning of the governance model - expected roles and responsibilities - candidate for the role need not be included at this time, since we're only choosing the governance model. Depending on the governance model chosen, we might have different people to be nominated. There will be a separate process for nominating the candidate. - the term of governance: is it for life? 5 years? 10 years? Who can submit the proposal? Python core developers. Individual core devs can submit a proposal, or co-author the proposal with another core dev. How to submit the proposal? Proposal should be in a form of a PEP, and merged into peps repo before Oct 1 00:00:00 UTC. Proposals not merged after Oct 1 00:00:00 UTC will not be considered. *Oct 1 - Nov 15: Review period.* All core developers will review the PEPs, and ask any questions to the PEP author. This timeline allows for enough time for all core devs to carefully review each PEPs, and for authors to respond. There will be two parts of this: *Review phase 1: Oct 1- Nov 1:* Allow changes and tweaks to the proposed PEPs. I figured people will have questions and will need to clarify the PEPs during this period. But if we want the PEP to be final by Oct 1, that's fine by me. maybe allow typo fixes still. *Review phase 2: Nov 1 00:00:00 UTC*: No more changes to the above PEPs. No more tweaks to these PEPs. PRs to these PEPs should be rejected. This is the final chance to carefully review all governance PEPs, and formulate your decisions. *Nov 15 00:00:00 UTC: Voting for new governance model starts, and will go for 2 weeks* Send reminders for folks to vote. Who can vote: Only core developers can vote. *Vote will be anonymous.* *We will use the system used to elect PSF board members.* *Dec 1 00:00:00 UTC: Voting ended*. The most voted proposal will be accepted. Depending on the chosen governance model, we'll begin nominating candidates to fill the role(s). *Dec 10 00:00:00 UTC Deadline for nominating candidates to fill the role* Maybe just one PEP to list all the nominations, instead of separate PEPs of each candidates. Who can nominate: Python core developers Who can be nominated: Python core developers *Dec 15 00:00:00 UTC Voting for new successor starts* (Depends on the governance model chosen on Dec 1) *Who can vote:* *Only core developers can vote.* *Vote will be anonymous.* *We will use the system used to elect PSF board members.* *Jan 1 00:00:00 UTC Voting for new successor ends.* Most voted candidate(s) is chosen. The PSF's Code of Conduct applies to all interactions with core devs regarding this process, including interactions in any mailing lists, zulip, IRC, twitter, GitHub, backchannels. Questions 1. For the purpose of eligibility (for voting or writing the PEP), who are considered as "core developers"? Anyone in python-committers? Anyone on Python Core GitHub team? Anyone with commit bit? What about core developers of alternate implementation (PyPy, IronPython, etc) 2. Are people ok UTC timezone? 3. Should this be a PEP? Mariatta

14 27

View logs on VSTS?
by Antoine Pitrou 4 আগস্ট, 2018

4 আগস্ট, 2018

Hello, I may be missing something, but I fail to view the "tests" log in this failed CI build: https://python.visualstudio.com/cpython/_build/results?buildId=20701&view=l… Regards Antoine.

3 3

List of all core developers
by M.-A. Lemburg 4 আগস্ট, 2018

4 আগস্ট, 2018

It's become fairly obvious that we are missing a list of core developers on some site. One we can use as reference and one which core devs can also show to other to prove they are core developers. I guess the natural place for such a list is the dev guide, but we could also use a page on www.python.org, if that's easier to maintain. Regarding format, I'd suggest to use the same as PSF Fellows list: https://www.python.org/psf/members/#fellows Thoughts ? Note: Asking for this now is not completely unintentional. The EuroPython Society has something to announce which will require such a list. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts (#1, Aug 01 2018) >>> Python Projects, Coaching and Consulting ... http://www.egenix.com/ >>> Python Database Interfaces ... http://products.egenix.com/ >>> Plone/Zope Database Interfaces ... http://zope.egenix.com/ ________________________________________________________________________ ::: We implement business ideas - efficiently in both time and costs ::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ http://www.malemburg.com/

10 27