On Wed, 25 Jan 2017 at 06:29 M.-A. Lemburg email@example.com wrote:
On 25.01.2017 13:30, Antoine Pitrou wrote:
Le 25/01/2017 à 10:19, M.-A. Lemburg a écrit :
All that said, I believe a having a Python 2.7 style long support version for Python 3 would be nice and have a stabilizing effect which our user base would appreciate.
Trying to enforce such a level of commitment (if we're talking 5+ years of bugfix maintenance on an increasingly divergent codebase) in the already controversial PEP 407 is probably not a good idea. A separate PEP is in order.
This is not about enforcing commitment, it's about opening up our release process to be able to apply fixes on such an LTS beyond what we'd normally do.
I'm pretty sure we can find core developers or attract new ones who'd be happy to be able to help fix issues in Python releases they use in their day job rather than work on releases which they won't be able to use in their day for at least another few years due to company policies.
I don't think that's necessarily true. I'm sure core developers fix bugs in Python 2.7 if they run into them and it affects their work, but beyond that I don't know how many of us are actually helping to maintain Python 2.7 beyond that (I for one immediately ignore all issues relating to 2.7 only at this point). And attracting people to help is typically not an issue, it's getting enough core developers to do code reviews to keep up with the workload.
I also believe that the PSF should start stepping up and invest some money into helping with Python support. A lot of money is being spent on community work, but hardly any on development work at the moment.
By doing so, the PSF could also attract more sponsors, since sponsoring would then have a real tangible benefit to the sponsors.
We'd just say: this is our new LTS release (e.g. Python 3.7) and then move on until we're confident again that the feature set has stabilized enough to create a new LTS release.
In practice you wouldn't just "move on" but have to maintain that LTS release (which is the whole point). If we're talking something past the 2 years timerange, you can't just impose that on all core developers, so you need a subgroup of maintainers dedicated to that LTS release.
See above; this is about opening doors and lifting restrictions.
-- Marc-Andre Lemburg eGenix.com
Professional Python Services directly from the Experts (#1, Jan 25 2017)
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/
python-committers mailing list firstname.lastname@example.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/