python-committers October 2015

python-committers@python.org

12 participants
5 discussions

Idea: listing commercial prioritisation options as a new section in the developer guide?

by Nick Coghlan

Hi folks, A question I occasionally get asked by organisations that use Python commercially but don't currently employ any core developers themselves is "How can we prioritise getting particular issues fixed/reviewed/merged?". A related problem we have in the PSF is knowing which core developers are available for freelance & consulting work when organisations approach us regarding larger projects. At the moment, those kinds of referrals are reliant on Board members' personal knowledge of who amongst the core development team is open to that style of employment and making direct introductions, which is neither transparent nor fair. As such, what do folks think of the idea of a new, *opt-in* section in the developer guide, similar to the current experts index, but allowing core developers to indicate the ways in which we're willing to provide paid support. I'd see four likely sections in such a document: * Freelance consultants: folks that are available for contract opportunities at the individual level * Consulting companies: folks that are available for contract opportunities, but work for larger consulting organisations rather than contracting directly * Commercial redistributors: folks that work for commercial Python redistributors and are willing and able to both help in getting customer issues resolved and in acting as a point of escalation for their colleagues * Direct employment: folks that work directly for organisations that use Python extensively, and hence are able to act as a point of escalation for their colleagues The latter three categories would be further broken out by employer, while the first would just be a list of names and professional contact details. Regards, Nick. P.S. Disclosure: I do have my own interests in mind here, both personally and professionally. At a personal level, I'm a strong believer in "If you want me to care about your opinion on how I spend my time, pay me", so it makes sense to me to make it easy for more commercially-minded core developers to say "Pay me or my employer if you'd like to influence my time allocation". Professionally, it's definitely in my interests for both Python core developers and commercial Python redistributors to be recognised as a group for their expertise and overall influence on the technology sector. -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia

5 years, 5 months

PSA: replace your DSA keys for SSH

by Georg Brandl

Hi all, newer OpenSSH versions (7.0+) default to not allowing ssh-dss keys for public key authentication. If you experience "permission denied" errors, this (currently) comes from the client side only and hg.python.org will accept these keys if you enable them using the PubkeyAcceptedKeyTypes option in your SSH config file. Of course ssh-dss is being phased out for a reason; we'd like to invite everybody who has only DSA keys submitted for hg.python.org access to send an RSA (min. 1024 bits) or ED25519 key to hgaccounts(a)python.org. cheers, Georg

5 years, 12 months

Initial Motivations & Affiliations page has been merged

by Nick Coghlan

Based on the thread a few weeks ago and the subsequent issue tracker discussion at http://bugs.python.org/issue25194, I just committed an initial version of a "Motivations & Affiliations" page in the developer guide. When the site next updates, that should appear at https://docs.python.org/devguide/motivations.html (it's the last section in the main TOC, with the link appearing right at the bottom of the main page). In the meantime, the diff can be seen at https://hg.python.org/devguide/rev/0f0ff7d19cfc The first important section for core contributors is the "Limitations on Scope": https://hg.python.org/devguide/rev/0f0ff7d19cfc#l3.31 That section spells out: * this is optional, so only fill it in if you think it's in your personal best interests to do so * for those of us working for commercial redistributors and PSF Sponsor Members, there's a financial transparency consideration, so we should be inclined towards filling out an entry * folks that are available for consulting or contract work are likely to want to fill it out as a possible source of client lead generation (either directly or via the PSF) The second important section is the initial guidelines for filling out entries, which are written in a ReST comment: https://hg.python.org/devguide/rev/0f0ff7d19cfc#l3.77 It's hard to judge how well that initial set of guidelines is going to work with just the one entry, so I expect they may need to be revised as more people start adding their own entries. However, I figured it would be better to put the page live and have that discussion here as people start filling it out, rather than speculating further on the issue tracker. Regards, Nick. -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia

6 years

Python 3.6 Release Schedule Details

by Ned Deily

FYI - I've just updated PEP 494 with a fleshed-out 3.6.0 release schedule. The 3.6 schedule is generally similar to the successful 18-month development and release cycle used in recent releases but with a few significant changes. The main difference is that the 3.6 schedule takes advantage of the earlier creation of the 3.5 branch (Thanks, Larry!), which allowed code for 3.6 to be checked in starting at 3.5.0beta1, rather than later at release candidate 1 as in previous release cycles. This provides an additional 11 weeks of overlap between 3.5.0 and 3.6.0, accelerating the release date for 3.6.0 without significantly reducing the overall release cycle duration. Another change has been to add a fourth beta and drop the third release candidate. My gut feeling from the past several releases is that a lot of feature code does not get checked in until close to the b1 feature code cutoff so that extending the beta phase should result in more testing exposure for all features. And I would like to reduce the amount of churn during the release candidate phase: a worthy goal is to make no changes after rc1, so that an rc2 would be be made only if absolutely necessary. Also note that the alpha1 build is scheduled for two weeks before PyCon 2016 and alpha2 will occur a week after the conclusion of the PyCon development sprints. Beta1, the feature code cutoff, occurs at the beginning of September just after the US Labor Day holiday and the traditional end of summer, with the final release in mid-December 2016. A comparison between the 3.5.0 and 3.6.0 release cycles shows the differences (in days): phase 3.5.0 3.6.0 ====== ===== ===== dev 363 357 alpha 105 114 beta 77 89 rc 35 14 total 580 574 As always, the schedule will be subject to changes as necessary - and comments welcomed - but I'm hoping that with this schedule we will be able to once again achieve a high-quality release and still be able to move the release date up without straining our development, testing, and release team resources. So keep those PEPs, other features, and bug fixes coming in. In the immortal words of Larry: "Let the wild rumpus begin!" --Ned PEP: 494 Title: Python 3.6 Release Schedule Last-Modified: 01-Oct-2015 Author: Ned Deily <nad(a)acm.org> Status: Active Type: Informational Content-Type: text/x-rst Created: 30-May-2015 Python-Version: 3.6 Abstract ======== This document describes the development and release schedule for Python 3.6. The schedule primarily concerns itself with PEP-sized items. Release Manager and Crew ======================== - 3.6 Release Manager: Ned Deily - Windows installers: Steve Dower - Mac installers: Ned Deily - Documentation: Georg Brandl 3.6 Lifespan ============ 3.6 will receive bugfix updates approximately every 3-6 months for approximately 18 months. After the release of 3.7.0 final, a final 3.6 bugfix update will be released. After that, it is expected that security updates (source only) will be released until 5 years after the release of 3.6 final, so until approximately December 2021. Release Schedule ================ 3.6.0 schedule -------------- - 3.6 development begins: 2015-05-24 - 3.6.0 alpha 1: 2016-05-15 - 3.6.0 alpha 2: 2016-06-12 - 3.6.0 alpha 3: 2016-07-10 - 3.6.0 alpha 4: 2016-08-07 - 3.6.0 beta 1: 2016-09-07 (No new features beyond this point.) - 3.6.0 beta 2: 2016-10-02 - 3.6.0 beta 3: 2016-10-30 - 3.6.0 beta 4: 2016-11-20 - 3.6.0 candidate 1: 2016-12-04 - 3.6.0 candidate 2 (if needed): 2016-12-11 - 3.6.0 final: 2016-12-16 Features for 3.6 ================ Proposed changes for 3.6: * PEP 447, Add __getdescriptor__ method to metaclass * PEP 498, Literal String Formatting * PEP 499, python -m foo should bind sys.modules['foo'] in additon to sys.modules['__main__'] * PEP 501, Translation ready string interpolation Copyright ========= This document has been placed in the public domain. -- Ned Deily nad(a)acm.org -- []

6 years

SSH problems attempting to access hg.python.org

by Nick Coghlan

Hi folks, After getting some publickey errors from hg.python.org earlier, I'm now consistently getting "Too many authentication failures for hg". I've checked my SSH keys, and they're validating against other services OK, so this appears to be a problem with hg.python.org specifically. Could someone with the appropriate admin access take a look at the server and see what might be going on? Regards, Nick. P.S. Relevant public key fingerprint (in both MD5 and SHA256 format): 2048 MD5:07:7b:9c:2f:f1:e4:bb:f7:a2:2a:c9:f1:2e:6d:f1:ec ncoghlan@llamedos (RSA) 2048 SHA256:kz2qX96utlWroXvMf75x2WFiL0o2SEeHnX7eJStd3wc ncoghlan@llamedos (RSA) -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia

6 years

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

python-committers October 2015