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
I just thought I would quickly update everyone on where things stand in
terms of fixing our development process to be easier for us to keep up with
patches.
First, I have given Donald Stufft and Nick Coghlan a deadline of October 31
-- Halloween in North America -- to get demo instances of their approaches
for tweaking our approaches (and they were the only ones to propose
anything so if you are asking "what about considering XXX?", it's because
no one proposed it and stepped up to make sure it happened if their
approach was chosen). Nick is proposing using Kalithea and his proposal is
found at https://www.python.org/dev/peps/pep-0474/ . Donald is proposing
GitHub + Phabricator -- although the Phabricator bit is optional for people
-- and his proposal is at https://www.python.org/dev/peps/pep-0481/ . The
plan is to get the test instances up, play with them to see what it looks
like from both a core dev and contributor perspective and get opinions from
various people of different levels of experience as to how the proposals
feel. My hope is to make a decision by January 1 so we can switch over
ancillary repositories like the devguide, devinabox, and the benchmark
suite quickly and then work towards switching the cpython repository.
Second, if you find Misc/NEWS a pain when doing merges then have a look at
http://bugs.python.org/issue18967 and look at the recent posts. Larry
Hastings is proposing a wrapper around `hg commit` that will create
individual files per NEWS entry so that you can just pull the file forward
in a merge and thus have no issues. We probably need feedback from Windows
developers more than anyone since this would make using TortoiseHg a bigger
pain since you would need to generate the NEWS file separately before doing
your commit while everyone else has it integrated into the commit process.
The long term goal is to put a field in the issue tracker for the NEWS
entry so that it's directly attached to the issue related to the change and
makes it easier to update before a release.
So that's the current status. As always, if you want to participate in any
of this you should join the core-workflow@ mailing list.
I've made some changes to asyncio but I've run into a snag -- I can't merge
the changes from 3.5 into 3.6 (the default branch). It seems some other
changes to 3.5 haven't been merged and I don't want to just commit the
default merge outcome (which affected a huge number of files).
I thought the merge policy was to relentlessly merge everything from 3.5
into 3.6 (using null merges to mark decisions not to copy a specific diff)?
--
--Guido van Rossum (python.org/~guido)
Just a quick update on 3.6 release plans. First, thanks for the kind words. With their help, I will try my best to follow the high standards set by our previous release managers: Larry, Benjamin, Georg, Barry, Martin, et al. As you may have noticed, we don't have a release schedule for 3.6 published yet. One, we've all been busy getting 3.5.0 out the door. Two, with the experimental overlap of next release feature development with the stabilization of the current feature release, feature work for 3.6 has been underway since the feature code freeze for 3.5 (3.5 beta 1). We hope to take advantage of that overlap to shorten the release cycle for 3.6. Three, since accepting the RM role for 3.6 earlier this year, unexpected events - primarily a transcontinental relocation - have taken most of my time for the past few months. Things are now settling back down to a new normal and, starting in about a week, I look forward to devoting a significant amount of time to Python-dev, and specifically 3.6, going forward. I plan to have a 3.6 schedule out for review by Sep 30. In the meantime, please keep up the good work on the already identified features for 3.6 and discussions about additional ones.
Here's to another great release!
--Ned
--
Ned Deily
субота, 19-вер-2015 23:55:44 Nathaniel Smith написано:
> OTOH I guess if there is anyone out there who's intentionally using
> stacklevel=1 they might be reasonably surprised at this change.
That is why I ask on Python-Dev instead of just open an issue.
But I doubt that there is such case.
On behalf of the Python development community and the Python 3.5 release
team, I'm proud to announce the availability of Python 3.5.0. Python
3.5.0 is the newest version of the Python language, and it contains many
exciting new features and optimizations.
You can read all about what's new in Python 3.5.0 here:
https://docs.python.org/3.5/whatsnew/3.5.html
And you can download Python 3.5.0 here:
https://www.python.org/downloads/release/python-350/
Windows and Mac users: please read the important platform-specific
"Notes on this release" section near the end of that page.
We hope you enjoy Python 3.5.0!
//arry/
On behalf of the Python development community and the Python 3.5 release
team, I'm surprised to announce the availability of Python 3.5.0rc4,
also known as Python 3.5.0 Release Candidate 4.
Python 3.5.0 Release Candidate 3 was only released about a day ago.
However: during testing, a major regression was discovered, reported on
the issue tracker as #25027:
http://bugs.python.org/issue25027
Python 3.5 includes some big changes on how Python is built on Windows.
One of those changes resulted in Python processes on Windows exceeding
the maximum number of loadable shared libraries. As a result Windows
builds of Python could no longer run major Python software stacks like
Pandas and Jupyter. Fixing this required non-trivial last-minute changes
to the Windows build--and those changes need testing. We therefore
elected to insert an extra release candidate before the final release,
to get these changes into your hands as soon as possible, so that
Windows users could test these changes.
As with all other Python 3.5 releases to date, this is a preview
release, and its use is not recommended for production settings.
However, users are encouraged to test with Python 3.5.0rc4, /especially/
Windows users who build or make use of numerous external packages.
(Non-Windows users will find little difference between Python 3.5.0rc3
and Python 3.5.0rc4.)
You can find Python 3.5.0rc4 here:
https://www.python.org/downloads/release/python-350rc4/
Windows and Mac users: please read the important platform-specific
"Notes on this release" section near the end of that page.
Please kick the tires,
//arry/
p.s. Special thanks from the Python 3.5 release team to Christoph
Gohlke for the bug report!
On behalf of the Python development community and the Python 3.5 release
team, I'm relieved to announce the availability of Python 3.5.0rc3, also
known as Python 3.5.0 Release Candidate 3.
The next release of Python 3.5 will be Python 3.5.0 final. There should
be few (or no) changes to Python 3.5 between rc3 and final.
This is a preview release, and its use is not recommended for production
settings.
You can find Python 3.5.0rc3 here:
https://www.python.org/downloads/release/python-350rc3/
Windows and Mac users: please read the important platform-specific
"Notes on this release" section near the end of that page.
Happy hacking,
//arry/