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
3.5.1rc1 is tagged, merged, and pushed back into the central repo. At
this point I don't plan to merge further changes from hg.python.org into
3.5.1 final. If you have an important bug fix that didn't make it into
3.5.1rc1 and *has* to go into 3.5.1 final, add me to the issue and we'll
talk about it. If it happens I'll have to manually cherry-pick the change.
I've added a 3.5.2rc1 section to Misc/NEWS; please add new entries there.
Happy holidays,
//arry/
On behalf of the Python development community and the Python 3.5 release
team, I'm pleased to announce the availability of Python 3.5.1rc1.
Python 3.5.1 will be the first update for Python 3.5. Python 3.5 is the
newest version of the Python language, and it contains many exciting new
features and optimizations.
You can see what's changed in Python 3.5.1rc1 (as compared to 3.5.0) here:
https://docs.python.org/3.5/whatsnew/changelog.html
And you can download Python 3.5.1 here:
https://www.python.org/downloads/release/python-351rc1/
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.1!
//arry/
Sorry for the short notice of this schedule, but... here goes:
Sat Dec 05 - tag 3.4.4rc1
Sun Dec 06 - release 3.4.4rc1
Sat Dec 19 - tag 3.4.4 final
Sun Dec 20 - release 3.4.4 final
The reason for the short notice: we may have to change personnel for
this release, and we need to work around some holiday vacation schedules
too. However, note that we have two weeks for the RC release. Because
of the short notice, I plan to be a little more flexible about changes
between RC1 and final. It also means we can pretty easily add a second
RC if we need to.
Unless something amazing happens, 3.4.4 will be the final release of 3.4
with binary installers. 3.4 will also move into "security fixes only"
mode at that time.
Best wishes, and again my apologies for the short notice,
//arry/
Most of the emails from bugs.python.org (and review tool) end up being
marked as spam in gmail. I consistently miss 70% of them. Is it
possible to fix this?
Yury
At the request of the platform experts, 3.5.1 is now scheduled to happen
simultaneously with 2.7.11. That means:
Saturday November 21, 2015
tag 3.5.1rc1
Sunday November 22, 2015
release 3.5.1rc1
Saturday December 5, 2015
tag 3.5.1 final
Sunday December 6, 2015
release 3.5.1 final
I'll update the release schedule soon,
//arry/