Re: [python-committers] [Python-Dev] 3.7.2rc1 and 3.6.8rc1 cutoffs ahead, last 3.6.x bugfix release!

[Petr Viktorin]

On 12/23/18 2:08 AM, Nick Coghlan wrote:
On Thu., 20 Dec. 2018, 3:46 am Brett Cannon  wrote:



On Wed, 19 Dec 2018 at 06:01, Victor Stinner mailto:vstin...@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.html


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.

___
python-committers mailing list
python-committers@python.org

Re: [python-committers] [Python-Dev] 3.7.2rc1 and 3.6.8rc1 cutoffs ahead, last 3.6.x bugfix release!

[Nick Coghlan]

On Thu., 20 Dec. 2018, 3:46 am Brett Cannon 
> On Wed, 19 Dec 2018 at 06:01, Victor Stinner  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.html

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).

Cheers,
Nick.



>
>>
>>
___
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/

Re: [python-committers] [Python-Dev] 3.7.2rc1 and 3.6.8rc1 cutoffs ahead, last 3.6.x bugfix release!

[Gregory P. Smith]

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.

-gps


On Wed, Dec 19, 2018 at 9:46 AM Brett Cannon  wrote:

> [Dropping python-dev so we don't end up swamping the python-committers
> admins -- i.e. me :) -- with posts held for moderation]
>
> On Wed, 19 Dec 2018 at 06:01, Victor Stinner  wrote:
>
>> Hi,
>>
>> I am working in the Red Hat "Python-maint" team which is maintaining
>> Python 3.6 as the main Python interpreter in RHEL 8, which will likely
>> be supported for at least 10 years. And we have been supporting Python
>> 2.7 in RHEL 7. So obviously, being able to benefit of the upstream
>> effort and infra to have a Python 3.6 Long Time Support (LTS) would
>> help us :-)
>>
>> The question is more who else would benefit from that and is it worth
>> it? I don't want Python upstream to pay the price of the maintenance
>> burden of RHEL 8 lifecycle.
>
>
> And for me that extends to Ubuntu LTS releases as well.
>
>
>> 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
>
>
>>
>>
>> The Linux kernel also have multiple LTS kernel which are supported
>> longer than usual releases: they are now supported for 6 years. See
>> "Longterm" at:
>>
>>https://www.kernel.org/category/releases.html
>
>
> The LKM has plenty of paid, full-time employees to keep those LTS kernels
> running upstream while we have nothing close to that. Even if we said "no
> one is expected to manage 3.6 changes" to let paid core devs keep 3.6
> going, that still adds overhead to other core devs who have no interest in
> keeping 3.6 alive for Canonical or RH's benefit (yes, the community gets
> benefits as well, but I would argue the pay-off isn't high enough for
> volunteers to be involved). Now if downstream vendors wanted to get
> together to pool their resources to make 3.6 a LTS-like release in a
> separate repo then I would be fine with that.
>
> I also think this puts Ned in a tough position to say "no" to the request
> if people start saying "I would love more free support!" ;) .
> ___
> 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/
>
___
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/

Re: [python-committers] [Python-Dev] 3.7.2rc1 and 3.6.8rc1 cutoffs ahead, last 3.6.x bugfix release!

[Brett Cannon]

[Dropping python-dev so we don't end up swamping the python-committers
admins -- i.e. me :) -- with posts held for moderation]

On Wed, 19 Dec 2018 at 06:01, Victor Stinner  wrote:

> Hi,
>
> I am working in the Red Hat "Python-maint" team which is maintaining
> Python 3.6 as the main Python interpreter in RHEL 8, which will likely
> be supported for at least 10 years. And we have been supporting Python
> 2.7 in RHEL 7. So obviously, being able to benefit of the upstream
> effort and infra to have a Python 3.6 Long Time Support (LTS) would
> help us :-)
>
> The question is more who else would benefit from that and is it worth
> it? I don't want Python upstream to pay the price of the maintenance
> burden of RHEL 8 lifecycle.


And for me that extends to Ubuntu LTS releases as well.


> 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


>
>
> The Linux kernel also have multiple LTS kernel which are supported
> longer than usual releases: they are now supported for 6 years. See
> "Longterm" at:
>
>https://www.kernel.org/category/releases.html


The LKM has plenty of paid, full-time employees to keep those LTS kernels
running upstream while we have nothing close to that. Even if we said "no
one is expected to manage 3.6 changes" to let paid core devs keep 3.6
going, that still adds overhead to other core devs who have no interest in
keeping 3.6 alive for Canonical or RH's benefit (yes, the community gets
benefits as well, but I would argue the pay-off isn't high enough for
volunteers to be involved). Now if downstream vendors wanted to get
together to pool their resources to make 3.6 a LTS-like release in a
separate repo then I would be fine with that.

I also think this puts Ned in a tough position to say "no" to the request
if people start saying "I would love more free support!" ;) .
___
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/

Re: [python-committers] [Python-Dev] 3.7.2rc1 and 3.6.8rc1 cutoffs ahead, last 3.6.x bugfix release!

[Serhiy Storchaka]

19.12.18 16:01, Victor Stinner пише:

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.


Unlikely the patch rate was constant. I suppose that more patches were 
created at earlier years. Additional time for fixing bugs in mainstream 
can decrease the number of necessary patches after the end of the 
official support.



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.


I think it is better to allow backporting all changes which will be 
backported to 3.7 (but not require this). At this stage we should not 
make risky changes in 3.7.



If we extend Python 3.6 lifetime, do we need a new release manager
when the initial lifetime (usually 5 years) ends?


It would be hard to maintain 3.6 after EOL for 3.7. So I suggest to just 
the same EOL for 3.6 and 3.7 (i.e. add 1.5 years for 3.6 lifetime). 
Fortunately Ned is the release manager of both 3.6 and 3.7.


___
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/

Re: [python-committers] [Python-Dev] 3.7.2rc1 and 3.6.8rc1 cutoffs ahead, last 3.6.x bugfix release!

[Victor Stinner]

Hi,

I am working in the Red Hat "Python-maint" team which is maintaining
Python 3.6 as the main Python interpreter in RHEL 8, which will likely
be supported for at least 10 years. And we have been supporting Python
2.7 in RHEL 7. So obviously, being able to benefit of the upstream
effort and infra to have a Python 3.6 Long Time Support (LTS) would
help us :-)

The question is more who else would benefit from that and is it worth
it? I don't want Python upstream to pay the price of the maintenance
burden of RHEL 8 lifecycle. 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.

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

The Linux kernel also have multiple LTS kernel which are supported
longer than usual releases: they are now supported for 6 years. See
"Longterm" at:

   https://www.kernel.org/category/releases.html

Victor
--
Night gathers, and now my watch begins. It shall not end until my death.
___
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/

Re: [python-committers] [Python-Dev] 3.7.2rc1 and 3.6.8rc1 cutoffs ahead, last 3.6.x bugfix release!

[Ned Deily]

https://discuss.python.org/t/3-7-2rc1-and-3-6-8rc1-cutoffs-ahead-last-3-6-x-bugfix-release/510/3?u=nad


OK, thanks to a lot of hard work by many of you, I think we are ready to
start the manufacturing of **3.7.2rc1** and **3.6.8rc1**.

For the **3.7 branch**, as usual feel free to continue to merge the
usual changes appropriate for a `bugfix` branch; unless otherwise marked
and agreed on as a **release blocker** for 3.7.2 final, any new 3.7
merges will be released in 3.7.3.

For the **3.6 branch**, as announced 3.6.8 is planned to be **the last
bugfix release** for the 3.6 series; future 3.6.x releases will be as
needed and contain **only security fixes** and source only. Of course,
if any release blocker regressions show up after 3.6.8rc1, we will
consider merging fixes for them. This means that, **as of now, the 3.6
branch is no longer open to normal bugfixes**, only security fixes and
release blocker regressions fixes and only with the approval of the
release manager. Therefore, as we have done with previous branches
moving to security-fix mode, merges to the 3.6 branch on the `cpython`
GitHub repo are now restricted to the release managers. If you feel a
change to 3.6 is needed either because it is a **release blocker
regression** in 3.6.8 or because it is a **security issue**, please
ensure there is a bpo issue describing the problem, mark it as **release
blocker** priority, and submit the necessary PR. At some point, on or
after the 3.6.8 release, we will be going through the open 3.6 PRs, open
PRs with the `needs backport to 3.6` label, and bpo issues marked for
3.6 and updating or closing them as needed. **Please do not mark new PRs
with the** `needs backport to 3.6` **label** unless you feel the
proposed change meets one of the criteria above.

Thanks for your help!

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

___
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/

Re: [python-committers] [Python-Dev] 3.7.2rc1 and 3.6.8rc1 cutoffs ahead, last 3.6.x bugfix release!

[Ned Deily]

On Dec 4, 2018, at 03:42, Ned Deily  wrote:
> https://discuss.python.org/t/3-7-2rc1-and-3-6-8rc1-cutoffs-ahead-last-3-6-x-bugfix-release/510

An update: as of the planned Friday cutoff, we still had a few open issues.  
Since 3.6.8 is the last planned bugfix for the 3.6 branch, I would like to make 
sure we leave it in as good a state as possible before it moves to 
security-fix-only mode.  Also, the Windows App Store support for 3.7.x that 
Steve D has been working on is in final review and it would be great to have 
that in the release candidate.  So I'm going to extend the cutoff for 3.7.2rc1 
and 3.6.8rc1 until **Monday, 12-10, end of day (AOE**), in other words **about 
30 hours from now**.   Thanks for all your efforts so far!


> We're reaching the end of the year and it's time for another pair of Python 3 
> maintenance releases, 3.7.2 and 3.6.8, before we ring out 2018.  Since there 
> are still some open release blocker issues and I haven't been bugging you 
> about them, I've moved the code cutoff for the release candidates to this 
> coming Friday, 12-07, by the end of the day (AOE).  That gives us all another 
> 4 days to review open issues and PRs.  Please give highest attention to any 
> release blockers you have been shepherding or reviewing.  Thanks!
> 
> A reminder: as previously announced, 3.6.8 is planned to be the last bugfix 
> release of the 3.6 series.  Python 3.6.0 was released on 2016-12-23, so by 
> the time 3.6.8 is released, 3.6.x will have been in bugfix mode almost 
> exactly 2 years.  When a new feature release is made and enters "bugfix" 
> mode, our policy has long been to continue to maintain the previous bugfix 
> branch for at least one more release and then move that branch to "security 
> fix only" mode.  3.7.0 (and 3.6.6) was released nearly six months ago and, 
> with the release of 3.6.8, there will have been two additional 3.6.x bugfix 
> releases since then.  So, barring any showstopper issues that might arise, 
> the upcoming 3.6.8rc1 is your last chance to make bugfix changes for 3.6.x.  
> Following the successful release of 3.6.8, only security fixes will be 
> accepted for the 3.6 branch and future 3.6.x releases will be source-only and 
> scheduled as needed; no further binary installers will be produced for 3.6.  
> Refer to the Dev Guid
 e 
> sections and release PEPs linked below for more information.
> 
> 
> https://devguide.python.org/devcycle/
> https://devguide.python.org/#branchstatus
> https://www.python.org/dev/peps/pep-0494/
> https://www.python.org/dev/peps/pep-0537/
> 
> --
>  Ned Deily
>  n...@python.org -- []
> 
> ___
> Python-Dev mailing list
> python-...@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> https://mail.python.org/mailman/options/python-dev/nad%40python.org

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

___
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/