On Dec 19, 2018, at 04:14, Serhiy Storchaka <storchaka@gmail.com> wrote:

Can we revise our policy and prolong the bug fixing mode for 3.6? 3.6 is the default Python in Ubuntu 18.04 LTS and RHEL 8. And due to several important syntax features it can be a minimal required version for long time.

We could but we are not going to now for multiple reasons.

I merged several PRs before releasing 3.6.8rc1, but there are still less trivial bugfix PRs which need more time for reviewing, and there are bugs for which no PR is created yet. There is also a number of documentation PRs. I propose to allow backporting bugfixes to 3.6 if they do not need excessive work, but stop to fix 3.6 only bugs. After migrating to GitHab, backporting became less painful, most of backports to 3.6 can be done automatically from master or from 3.7.

There are always going to be bugs that remain unfixed when a release branch moves from bugfix mode to security-fix only mode. That has been true for all previous Python branches.

So what, if anything, is different about 3.6?

I see two possibly significant differences:

• 3.6 is clearly the most widely adopted Python 3 release to date and is likely to be in the field longer than previous 3.x releases.

• As Serhiy notes, it is now easier for core developers to port changes to other branches.

What hasn't changed in 3.6?

• We have had many discussions about Python 3 release cycles in a number of different venues, e.g. in the mailing lists, at PyCon Language Summits, at Core Developer Sprints, etc. People have made many different arguments for how long a release cycle should be and how long we should maintain a release branch. In the end, we made a plan that started 3.5 years ago, one that we have been following and one that we have set expectations for us and for our downstream users, big and small.

• While the act of backporting a fix is obviously an important part of producing a maintenance release, it is not the only part. As Victor noted, there is the CI infrastructure that needs to be monitored and maintained, primarily our CI platforms and buildbots. And Victor knows better than almost anyone that those things require constant attention, even if the number of supported platforms and level of activity were somehow reduced. This activity is exhausting and has led to more than one case of core developer (near-)burnout. Besides that, there are less visible but very important activities that are part of our release process: monitoring of release activity, manufacturing releases, encouraging and monitoring downstream testing by third-party developers, distributors, and users, etc.

So, extending the bugfix support window of a release affects and is asking for significant commitments from core developers, release teams, infrastructure support, third-party users and distributors. It is not something to be taken lightly - especially when most of the people involved in these activities are volunteers and largely unpaid.

On Dec 19, 2018, at 13:24, Gregory P. Smith <greg@krypto.org> wrote:

Ned - and any release manager in this situation in the future - has a default valid answer to this request: No.

If we're ever going to do an "EL" or "LTS" Python, that should be decided and agreed upon *long before the end of its existing planned maintenance cycle* instead of right as it is ending. Ideally before the first x.y.0 with agreement of the release manager. Though it'd likely be fine to have that conversation about 3.7 as it is still young, the RM gets final say into if or how that would work.

I know that I won't be bothering with 3.6 backport/review work myself anymore outside of special circumstances.

I think Greg says it better than I could - thanks!

We have had several years to discuss this. There have been a number of proposals but none have resulted in a reviewed, approved PEP. Literally one day before the final bugfix release is not the time to make such a big change in our plans. It certainly is legitimate and necessary to consider such changes in the future when we have our new governance process in place and, at that time, we can consider revising our plans for 3.7 which is still relatively early in its bugfix phase. And, if there were concrete proposals with funding sources for co-ordinating extended support for 3.6, we should consider them. I think a reasonable target is to have a final discussion and decision made by the next Language Summit upcoming in May; there is plenty of work to be done before then, i.e. start new or revise exiting PEPs.

But in the absence of any of that at the moment, it would be a disservice to all to consider making such major changes and commitments now. And it's not something that I as release manager or any of us individually as core developers can or should do.

--Ned

P.S. Thanks for bringing this up, Serihy, and thanks for everyone's thoughtful responses.

-- Ned Deily nad@python.org -- []

On 12/23/18 2:08 AM, Nick Coghlan wrote:

On Thu., 20 Dec. 2018, 3:46 am Brett Cannon <brett@python.org <mailto:brett@python.org> wrote:

On Wed, 19 Dec 2018 at 06:01, Victor Stinner <vstinner@redhat.com
<mailto:vstinner@redhat.com>> wrote:


    For example, supporting a version means to
    have a working CI (Travis CI, AppVeyor, VSTS, buildbots). I would
    suggest to only support a very few platforms for the LTS. I
    propose to
    restrict to Linux. It doesn't mean to break other platforms on
    purpose, just to restrict CI to the bare minimum. If Microsoft is
    interested, we can also support Windows as well.


But that doesn't help someone like me who isn't working on Linux, so
it's still work to support just Linux compared to Windows or macOS.
Plus supporting just Linux in CI and such is still not free either.


    RHEL 7 is based on Python 2.7.5 which has been released in 2013 (5
    years ago) and there are 150 patches on top of it: it means that
    around 30 patches are added per year. I would suggest to have a very
    strict policy on which changes are backported into 3.6: only the
    most
    critical bugfixes, but all security fixes obviously.

    If we extend Python 3.6 lifetime, do we need a new release manager
    when the initial lifetime (usually 5 years) ends? Benjamin Peterson
    accepted to be the Python 2.7 release manager for 10 years
    (instead of
    5 years initially). We could ask Ned Deily about Python 3.6 LTS
    :-) We
    would need a group of people reviewing individual 3.6 pull
    requests to
    decide to pick them or not. I would volunteer to review these
    PRs and
    merge them.

    The idea isn't new, Nick Coghlan proposed a "ELPython" last year:

    https://github.com/elpython/elpython-meta


Was that when

If the unfinished question there is "... when Nick was still working for Red Hat?", then yeah, it was.

I knew RHEL 8 was coming with Py3.6 as the system Python, and wanted a way to avoid the anchoring effects that Alex Gaynor and I talked about a few years back in https://alexgaynor.net/2015/mar/30/red-hat-open-source-community/ and https://www.curiousefficiency.org/posts/2015/04/stop-supporting-python26.htm...

I still think ELPython is a good idea, as it should solve a bunch of the problems that Alex raised on the community side, while also helping commercial distributors (including Red Hat) provide the explicitly in demand commercial service of compatible *feature* backports to LTS releases (go look at the system Python 2.6 install in RHEL 6, for example - it includes a number of 2.7 features, such as collections.OrderedDict).

Red Hat's provided that service for years for their Linux kernels, and it's one of the capabilities that their customers most value.

The community benefit of allowing such backports to take place in a cross-vendor collaborative project is that it would allow popular backwards compatible features to be adopted by library authors more quickly, as they'd have the option of switching to relying on the EL variant of a release for a feature they wanted, rather than having to drop that release stream entirely.

However, I also deliberately designed the proposal to make it clear it was only going to happen as a *paid* activity, with a bright line for contributions where the only reason for a volunteer to take their change across that line would be because they wanted the new behaviour in the EL version themselves.

Thus the notion of a separate GitHub org, source-only releases, different runtime identification metadata, etc.

Actually pursuing that project would still need a PEP to spell out the relationship between CPython and the ELPython derivative, though.

Pursuing the project would also need credible commitments from redistributors to actually adopt the variant - the technical design in the README is explicitly constructed so it would work as a drop-in replacement for the RHEL 8 system Python, but at the time I left RH, Petr Viktorin and I didn't have agreement from management yet that that was a path the company wanted to go down (and it was only recently, when the RHEL 8 public beta dropped, that we gained the ability to discuss the commercial motivation for the idea with the upstream community).

(with my RH hat on; despite my personal address:)

If anyone wants to collaborate, I'd be happy go push the EL Python idea further. But, so far, we haven't found other organizations that would want to join the effort. (BTW, I think Victor asking CPython devs themselves was a very long shot, but at least it confirmed that the answer is "no".)

So it looks like we'll keep the status quo – Red Hat's patches to 3.6 will be available in Red Hat & CentOS repos.