[python-committers] Pace of change for Python 3.x

[Brett Cannon]

On Wed, 25 Jan 2017 at 06:29 M.-A. Lemburg <mal at egenix.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.

-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 at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20170125/f697bab8/attachment-0001.html>