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.
-Brett
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
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/