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