From antoine at python.org  Sat Dec  1 12:59:12 2018
From: antoine at python.org (Antoine Pitrou)
Date: Sat, 1 Dec 2018 18:59:12 +0100
Subject: [python-committers] *Important*: Python governance vote (December
 2018): Ballots Sent
In-Reply-To: <topic/496@discuss.python.org>
References: <topic/496@discuss.python.org>
Message-ID: <2dc53e89-6784-7d2c-fded-be67cf99d15b@python.org>


Hello,

I'm forwarding this for the benefit of all who don't follow Discourse
actively.

Regards

Antoine.
-------------- next part --------------
An embedded message was scrubbed...
From: "Ernest W. Durbin III" <python1 at discoursemail.com>
Subject: [Discussions on Python.org] [Committers] Python governance vote (December 2018): Ballots Sent
Date: Sat, 01 Dec 2018 11:23:28 +0000
Size: 7708
URL: <http://mail.python.org/pipermail/python-committers/attachments/20181201/19cff791/attachment.eml>

From chris at simplistix.co.uk  Sun Dec  2 09:42:19 2018
From: chris at simplistix.co.uk (Chris Withers)
Date: Sun, 2 Dec 2018 14:42:19 +0000
Subject: [python-committers] *Important*: Python governance vote
 (December 2018): Ballots Sent
In-Reply-To: <2dc53e89-6784-7d2c-fded-be67cf99d15b@python.org>
References: <topic/496@discuss.python.org>
 <2dc53e89-6784-7d2c-fded-be67cf99d15b@python.org>
Message-ID: <573b51e7-3060-f1e2-003f-27052527f850@simplistix.co.uk>

An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20181202/8467c413/attachment.html>

From chris at simplistix.co.uk  Sun Dec  2 09:46:23 2018
From: chris at simplistix.co.uk (Chris Withers)
Date: Sun, 2 Dec 2018 14:46:23 +0000
Subject: [python-committers] *Important*: Python governance vote
 (December 2018): Ballots Sent
In-Reply-To: <573b51e7-3060-f1e2-003f-27052527f850@simplistix.co.uk>
References: <topic/496@discuss.python.org>
 <2dc53e89-6784-7d2c-fded-be67cf99d15b@python.org>
 <573b51e7-3060-f1e2-003f-27052527f850@simplistix.co.uk>
Message-ID: <faf6cddb-5e61-342f-88ba-338aeee854d8@simplistix.co.uk>

An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20181202/58dfcc64/attachment.html>

From eric at trueblade.com  Sun Dec  2 09:57:04 2018
From: eric at trueblade.com (Eric V. Smith)
Date: Sun, 2 Dec 2018 09:57:04 -0500
Subject: [python-committers] *Important*: Python governance vote
 (December 2018): Ballots Sent
In-Reply-To: <faf6cddb-5e61-342f-88ba-338aeee854d8@simplistix.co.uk>
References: <topic/496@discuss.python.org>
 <2dc53e89-6784-7d2c-fded-be67cf99d15b@python.org>
 <573b51e7-3060-f1e2-003f-27052527f850@simplistix.co.uk>
 <faf6cddb-5e61-342f-88ba-338aeee854d8@simplistix.co.uk>
Message-ID: <af4eeca3-7faa-458e-36db-362ffb4b281e@trueblade.com>

On 12/2/2018 9:46 AM, Chris Withers wrote:
>
> In fact, it looks like https://github.com/python/voters is entirely 
> private. How does one get access to it?
>
Are you logged in to github with your python committer id?

Eric

> On 02/12/2018 14:42, Chris Withers wrote:
>>
>> The link you forwarded 404's for me. I can't see a "reply" button on 
>> https://discuss.python.org/t/python-governance-vote-december-2018-ballots-sent/496
>>
>> On 01/12/2018 17:59, Antoine Pitrou wrote:
>>> Hello,
>>>
>>> I'm forwarding this for the benefit of all who don't follow Discourse
>>> actively.
>>>
>>> Regards
>>>
>>> Antoine.
>>>
>>> _______________________________________________
>>> 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/
>>
>> _______________________________________________
>> 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/
>
> _______________________________________________
> 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/20181202/5acc9261/attachment-0001.html>

From antoine at python.org  Sun Dec  2 12:21:45 2018
From: antoine at python.org (Antoine Pitrou)
Date: Sun, 2 Dec 2018 18:21:45 +0100
Subject: [python-committers] *Important*: Python governance vote
 (December 2018): Ballots Sent
In-Reply-To: <af4eeca3-7faa-458e-36db-362ffb4b281e@trueblade.com>
References: <topic/496@discuss.python.org>
 <2dc53e89-6784-7d2c-fded-be67cf99d15b@python.org>
 <573b51e7-3060-f1e2-003f-27052527f850@simplistix.co.uk>
 <faf6cddb-5e61-342f-88ba-338aeee854d8@simplistix.co.uk>
 <af4eeca3-7faa-458e-36db-362ffb4b281e@trueblade.com>
Message-ID: <f7d84e59-fa17-2872-a94e-437669ce9226@python.org>


I may misremember, but I don't think Chris is a committer.

Regards

Antoine.


Le 02/12/2018 ? 15:57, Eric V. Smith a ?crit?:
> On 12/2/2018 9:46 AM, Chris Withers wrote:
>>
>> In fact, it looks like https://github.com/python/voters is entirely
>> private. How does one get access to it?
>>
> Are you logged in to github with your python committer id?
> 
> Eric
> 
>> On 02/12/2018 14:42, Chris Withers wrote:
>>>
>>> The link you forwarded 404's for me. I can't see a "reply" button on
>>> https://discuss.python.org/t/python-governance-vote-december-2018-ballots-sent/496
>>>
>>> On 01/12/2018 17:59, Antoine Pitrou wrote:
>>>> Hello,
>>>>
>>>> I'm forwarding this for the benefit of all who don't follow Discourse
>>>> actively.
>>>>
>>>> Regards
>>>>
>>>> Antoine.
>>>>
>>>> _______________________________________________
>>>> 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/
>>>
>>> _______________________________________________
>>> 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/
>>
>> _______________________________________________
>> 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/
> 
> _______________________________________________
> 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/
> 

From guido at python.org  Sun Dec  2 13:27:16 2018
From: guido at python.org (Guido van Rossum)
Date: Sun, 2 Dec 2018 10:27:16 -0800
Subject: [python-committers] *Important*: Python governance vote
 (December 2018): Ballots Sent
In-Reply-To: <f7d84e59-fa17-2872-a94e-437669ce9226@python.org>
References: <topic/496@discuss.python.org>
 <2dc53e89-6784-7d2c-fded-be67cf99d15b@python.org>
 <573b51e7-3060-f1e2-003f-27052527f850@simplistix.co.uk>
 <faf6cddb-5e61-342f-88ba-338aeee854d8@simplistix.co.uk>
 <af4eeca3-7faa-458e-36db-362ffb4b281e@trueblade.com>
 <f7d84e59-fa17-2872-a94e-437669ce9226@python.org>
Message-ID: <CAP7+vJKDP-1OnALkrwszn+eM819U8EQ+e3e9e4iA7K_Z4NFZUw@mail.gmail.com>

But he was (search the dev guide), and he is seeking to activate his GitHub
committer bit (see his python-dev emails). Can someone help him with that?

On Sun, Dec 2, 2018 at 9:21 AM Antoine Pitrou <antoine at python.org> wrote:

>
> I may misremember, but I don't think Chris is a committer.
>
> Regards
>
> Antoine.
>
>
> Le 02/12/2018 ? 15:57, Eric V. Smith a ?crit :
> > On 12/2/2018 9:46 AM, Chris Withers wrote:
> >>
> >> In fact, it looks like https://github.com/python/voters is entirely
> >> private. How does one get access to it?
> >>
> > Are you logged in to github with your python committer id?
> >
> > Eric
> >
> >> On 02/12/2018 14:42, Chris Withers wrote:
> >>>
> >>> The link you forwarded 404's for me. I can't see a "reply" button on
> >>>
> https://discuss.python.org/t/python-governance-vote-december-2018-ballots-sent/496
> >>>
> >>> On 01/12/2018 17:59, Antoine Pitrou wrote:
> >>>> Hello,
> >>>>
> >>>> I'm forwarding this for the benefit of all who don't follow Discourse
> >>>> actively.
> >>>>
> >>>> Regards
> >>>>
> >>>> Antoine.
> >>>>
> >>>> _______________________________________________
> >>>> 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/
> >>>
> >>> _______________________________________________
> >>> 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/
> >>
> >> _______________________________________________
> >> 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/
> >
> > _______________________________________________
> > 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/
> >
> _______________________________________________
> 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/
>


-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20181202/b4356900/attachment.html>

From brett at python.org  Sun Dec  2 20:55:03 2018
From: brett at python.org (Brett Cannon)
Date: Sun, 2 Dec 2018 17:55:03 -0800
Subject: [python-committers] *Important*: Python governance vote
 (December 2018): Ballots Sent
In-Reply-To: <CAP7+vJKDP-1OnALkrwszn+eM819U8EQ+e3e9e4iA7K_Z4NFZUw@mail.gmail.com>
References: <topic/496@discuss.python.org>
 <2dc53e89-6784-7d2c-fded-be67cf99d15b@python.org>
 <573b51e7-3060-f1e2-003f-27052527f850@simplistix.co.uk>
 <faf6cddb-5e61-342f-88ba-338aeee854d8@simplistix.co.uk>
 <af4eeca3-7faa-458e-36db-362ffb4b281e@trueblade.com>
 <f7d84e59-fa17-2872-a94e-437669ce9226@python.org>
 <CAP7+vJKDP-1OnALkrwszn+eM819U8EQ+e3e9e4iA7K_Z4NFZUw@mail.gmail.com>
Message-ID: <CAP1=2W5861QO0jKOx_k0FMbPWwPh6k_5BOS-1x-NPX4CxJC10Q@mail.gmail.com>

Chris never had himself added to GitHub. It's being dealt with.

On Sun, 2 Dec 2018 at 10:24, Guido van Rossum <guido at python.org> wrote:

> But he was (search the dev guide), and he is seeking to activate his
> GitHub committer bit (see his python-dev emails). Can someone help him with
> that?
>
> On Sun, Dec 2, 2018 at 9:21 AM Antoine Pitrou <antoine at python.org> wrote:
>
>>
>> I may misremember, but I don't think Chris is a committer.
>>
>> Regards
>>
>> Antoine.
>>
>>
>> Le 02/12/2018 ? 15:57, Eric V. Smith a ?crit :
>> > On 12/2/2018 9:46 AM, Chris Withers wrote:
>> >>
>> >> In fact, it looks like https://github.com/python/voters is entirely
>> >> private. How does one get access to it?
>> >>
>> > Are you logged in to github with your python committer id?
>> >
>> > Eric
>> >
>> >> On 02/12/2018 14:42, Chris Withers wrote:
>> >>>
>> >>> The link you forwarded 404's for me. I can't see a "reply" button on
>> >>>
>> https://discuss.python.org/t/python-governance-vote-december-2018-ballots-sent/496
>> >>>
>> >>> On 01/12/2018 17:59, Antoine Pitrou wrote:
>> >>>> Hello,
>> >>>>
>> >>>> I'm forwarding this for the benefit of all who don't follow Discourse
>> >>>> actively.
>> >>>>
>> >>>> Regards
>> >>>>
>> >>>> Antoine.
>> >>>>
>> >>>> _______________________________________________
>> >>>> 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/
>> >>>
>> >>> _______________________________________________
>> >>> 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/
>> >>
>> >> _______________________________________________
>> >> 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/
>> >
>> > _______________________________________________
>> > 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/
>> >
>> _______________________________________________
>> 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/
>>
>
>
> --
> --Guido van Rossum (python.org/~guido)
> _______________________________________________
> 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/20181202/01ae46eb/attachment-0001.html>

From nad at python.org  Tue Dec  4 03:42:28 2018
From: nad at python.org (Ned Deily)
Date: Tue, 4 Dec 2018 03:42:28 -0500
Subject: [python-committers] 3.7.2rc1 and 3.6.8rc1 cutoffs ahead,
 last 3.6.x bugfix release!
Message-ID: <95B9F244-38A8-4E47-8E9D-6DAD289C84A2@python.org>

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


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 Guide 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
  nad at python.org -- []


From nad at python.org  Mon Dec 10 02:16:46 2018
From: nad at python.org (Ned Deily)
Date: Mon, 10 Dec 2018 02:16:46 -0500
Subject: [python-committers] [Python-Dev] 3.7.2rc1 and 3.6.8rc1 cutoffs
 ahead, last 3.6.x bugfix release!
In-Reply-To: <95B9F244-38A8-4E47-8E9D-6DAD289C84A2@python.org>
References: <95B9F244-38A8-4E47-8E9D-6DAD289C84A2@python.org>
Message-ID: <58C8B7D8-80EF-46D3-BCBE-4ACC95382D0A@python.org>

On Dec 4, 2018, at 03:42, Ned Deily <nad at python.org> 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 Guide 
> 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
>  nad at python.org -- []
> 
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/nad%40python.org

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


From mariatta at python.org  Mon Dec 10 13:57:54 2018
From: mariatta at python.org (Mariatta Wijaya)
Date: Mon, 10 Dec 2018 10:57:54 -0800
Subject: [python-committers] Blurb-it is now available
Message-ID: <CAGbohnZmRBVbZPcXJ_cyEMC7LrWx-koqEokMjjquCRrmySVAsg@mail.gmail.com>

Blurb-it is now available. For details, please see my post on discourse

https://discuss.python.org/t/blurb-it-is-now-available/528
?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20181210/b5dde7f0/attachment.html>

From nad at python.org  Tue Dec 11 15:07:48 2018
From: nad at python.org (Ned Deily)
Date: Tue, 11 Dec 2018 15:07:48 -0500
Subject: [python-committers] [Python-Dev] 3.7.2rc1 and 3.6.8rc1 cutoffs
 ahead, last 3.6.x bugfix release!
In-Reply-To: <58C8B7D8-80EF-46D3-BCBE-4ACC95382D0A@python.org>
References: <95B9F244-38A8-4E47-8E9D-6DAD289C84A2@python.org>
 <58C8B7D8-80EF-46D3-BCBE-4ACC95382D0A@python.org>
Message-ID: <BF1B33A9-4CC7-40FE-810E-5C52509993A1@python.org>

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
  nad at python.org -- []


From lukasz at langa.pl  Wed Dec 12 04:44:53 2018
From: lukasz at langa.pl (=?utf-8?Q?=C5=81ukasz_Langa?=)
Date: Wed, 12 Dec 2018 10:44:53 +0100
Subject: [python-committers] REMINDER: governance vote is closing by end of
 this week
Message-ID: <5EEC40FD-2515-4170-B187-AE5FE2A7AD93@langa.pl>

You have time until December 16th AoE to rank proposals and cast your ballot. More information in PEP 8001.

Note: reading the candidate PEPs will take you a while. Don't wait until Sunday.

- ?

From nad at python.org  Tue Dec 11 22:14:04 2018
From: nad at python.org (Ned Deily)
Date: Tue, 11 Dec 2018 22:14:04 -0500
Subject: [python-committers] [RELEASE] Python 3.7.2rc1 and 3.6.8rc1 now
 available for testing
Message-ID: <091E715F-EC84-4796-B193-D96414F4D62E@python.org>

https://blog.python.org/2018/12/python-372rc1-and-368rc1-now-available.html


Python 3.7.2rc1 and 3.6.8rc1 are now available. 3.7.2rc1 is the release
preview of the next maintenance release of Python 3.7, the latest
feature release of Python. 3.6.8rc1 is the release preview of the next
and last maintenance release of Python 3.6, the previous feature
release of Python. Assuming no critical problems are found prior to
2018-12-20, no code changes are planned between these release
candidates and the final releases. These release candidates are
intended to give you the opportunity to test the new security and bug
fixes in 3.7.2 and 3.6.8. We strongly encourage you to test your
projects and report issues found to bugs.python.org as soon as
possible. Please keep in mind that these are preview releases and,
thus, their use is not recommended for production environments.

You can find these releases and more information here:
    https://www.python.org/downloads/release/python-372rc1/
    https://www.python.org/downloads/release/python-368rc1/


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


From mariatta at python.org  Sun Dec 16 15:48:19 2018
From: mariatta at python.org (Mariatta Wijaya)
Date: Sun, 16 Dec 2018 12:48:19 -0800
Subject: [python-committers] REMINDER: governance vote is closing by end
 of this week
In-Reply-To: <5EEC40FD-2515-4170-B187-AE5FE2A7AD93@langa.pl>
References: <5EEC40FD-2515-4170-B187-AE5FE2A7AD93@langa.pl>
Message-ID: <CAGbohnZeK1Ukg5axbktg_c2b8XOCAQAyF70Ba9P=5DE1m22G9Q@mail.gmail.com>

You have about 15 hours 12 minutes left to vote, if you haven't already.

On Wed, Dec 12, 2018, 1:44 AM ?ukasz Langa <lukasz at langa.pl wrote:

> You have time until December 16th AoE to rank proposals and cast your
> ballot. More information in PEP 8001.
>
> Note: reading the candidate PEPs will take you a while. Don't wait until
> Sunday.
>
> - ?
> _______________________________________________
> 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/20181216/74a2c6ef/attachment.html>

From tjreedy at udel.edu  Mon Dec 17 03:10:30 2018
From: tjreedy at udel.edu (Terry Reedy)
Date: Mon, 17 Dec 2018 03:10:30 -0500
Subject: [python-committers] Voting thank you
Message-ID: <1baa05a3-c4b2-9ad5-2f37-7b2161cf5cce@udel.edu>

I just read the PEPs and voted (with a few hours to spare).  I want to 
thank the people who organized the voting, wrote the summary of other 
projects, wrote the PEPs, and who helped the PEP authors improve the 
proposals.

I like the ranking system.  Even if my (mild) first choice (tonight) 
does not 'win', the rest of my ranks still have an effect on the outcome.

I expect I can live with whatever choice the rest of you make.  Any 
change is an experiment.  If it does not work, I expect we will try 
something different.

--
Terry Jan Reedy


From ernest at python.org  Mon Dec 17 08:53:03 2018
From: ernest at python.org (=?utf-8?Q?ernest=40python.org?=)
Date: Mon, 17 Dec 2018 08:53:03 -0500
Subject: [python-committers] Python governance vote (December 2018): Results
Message-ID: <etPan.5c17aa3f.7778a0ed.100e2@python.org>


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

# Python governance vote (December 2018)

As described in [PEP 8001](https://www.python.org/dev/peps/pep-8001/), the governance election has been completed.

The result is that **[PEP 8016: The Steering Council Model (Smith, Stufft)](https://www.python.org/dev/peps/pep-8016/) has been selected as the winner**.

- - Supervisor: Ernest W. Durbin III <ernest at python.org>
- - Announced end of poll: 2018-12-17T12:00:00Z
- - Actual time poll closed: 2018-12-17T12:00:02Z
- - Authorized voters: 94 ([CPython core developers with a known email-address](https://github.com/python/voters/blob/bb4bceda896c38177e6d9c3c2437f63a5edb23dc/2018-12-01-governance-election.csv))
- - Actual votes cast: 62
- - Number of winning choices: 1
- - [Condorcet completion rule](https://civs.cs.cornell.edu/rp.html): Minimax

## Result

1. **[PEP 8016: The Steering Council Model (Smith, Stufft)](https://www.python.org/dev/peps/pep-8016/)**
? - (Condorcet winner: wins contests with all other choices)

2. [PEP 8012: The Community Governance Model (Langa)](https://www.python.org/dev/peps/pep-8012/)
? - loses to PEP 8016: The Steering Council Model (Smith, Stufft) by 40?22

3. [PEP 8011: Python Governance Model Lead by Trio of Pythonistas (Wijaya, Warsaw)](https://www.python.org/dev/peps/pep-8011/)
? - loses to PEP 8016: The Steering Council Model (Smith, Stufft) by 37?20
? - loses to PEP 8012: The Community Governance Model (Langa) by 34?28

4. [PEP 8015: Organization of the Python community (Stinner)](https://www.python.org/dev/peps/pep-8015/)
? - loses to PEP 8016: The Steering Council Model (Smith, Stufft)by 41?18
? - loses to PEP 8011: Python Governance Model Lead by Trio of Pythonistas (Wijaya, Warsaw) by 33?24

5. [PEP 8014: The Commons Governance Model (Jansen)](https://www.python.org/dev/peps/pep-8014/)
? - loses to PEP 8016: The Steering Council Model (Smith, Stufft) by 50?9
? - loses to PEP 8015: Organization of the Python community (Stinner) by 38?18

6. [PEP 8010: The Technical Leader Governance Model (Warsaw)](https://www.python.org/dev/peps/pep-8010/)
? - loses to PEP 8016: The Steering Council Model (Smith, Stufft) by 44?15
? - loses to PEP 8014: The Commons Governance Model (Jansen) by 30?28

7. [PEP 8013: The External Council Governance Model (Dower)](https://www.python.org/dev/peps/pep-8013/)
? - loses to PEP 8016: The Steering Council Model (Smith, Stufft) by 55?6
? - loses to PEP 8010: The Technical Leader Governance Model (Warsaw) by 38?17

8. Further discussion
? - loses to PEP 8016: The Steering Council Model (Smith, Stufft) by 57?4
? - loses to PEP 8013: The External Council Governance Model (Dower) by 32?29

### Result details

| ? ? ? ? ?| PEP 8016 | PEP 8012 | PEP 8011 | PEP 8015 | PEP 8014 | PEP 8010 | PEP 8013 |Discussion|
|----------|----------|----------|----------|----------|----------|----------|----------|----------|
| PEP 8016 | - |40 |37 |41 |50 |44 |55 |57 |
| PEP 8012 |22 | - |34 |33 |40 |40 |48 |48 |
| PEP 8011 |20 |28 | - |33 |42 |42 |52 |51 |
| PEP 8015 |18 |22 |24 | - |38 |36 |47 |48 |
| PEP 8014 | 9 |18 |16 |18 | - |30 |40 |38 |
| PEP 8010 |15 |20 |14 |22 |28 | - |38 |43 |
| PEP 8013 | 6 | 9 | 9 |12 |14 |17 | - |32 |
|Discussion| 4 |14 |10 |13 |23 |18 |29 | - |

### Ballot report

#### Choices

- - 0. PEP 8010: The Technical Leader Governance Model (Warsaw) (changelog)
- - 1. PEP 8011: Python Governance Model Lead by Trio of Pythonistas (Wijaya, Warsaw) (changelog
- - 2. PEP 8012: The Community Governance Model (Langa) (changelog)
- - 3. PEP 8013: The External Council Governance Model (Dower) (changelog)
- - 4. PEP 8014: The Commons Governance Model (Jansen) (changelog)
- - 5. PEP 8015: Organization of the Python community (Stinner) (changelog)
- - 6. PEP 8016: The Steering Council Model (Smith, Stufft) (changelog)
- - 7. Further discussion

#### Ballots in randomized order

|0.|1.|2.|3.|4.|5.|6.|7.|
|---|---|---|---|---|---|---|---|
|8|5|1|7|4|3|2|6|
|8|3|2|4|6|5|1|7|
|6|1|4|7|5|3|3|8|
|3|2|7|5|4|6|1|8|
|2|1|4|6|8|5|3|7|
|7|2|3|6|4|7|1|5|
|8|8|1|3|2|8|3|4|
|6|1|2|8|4|3|5|7|
|6|1|8|8|8|3|6|7|
|6|1|2|7|4|3|5|8|
|1|2|6|5|7|4|3|8|
|1|5|7|6|3|8|2|4|
|2|1|5|8|8|8|6|7|
|4|4|3|2|4|4|4|1|
|2|1|6|8|5|7|4|3|
|4|3|8|7|6|1|2|5|
|8|3|4|8|8|4|1|7|
|2|1|8|6|4|7|3|5|
|3|7|1|8|5|4|2|6|
|6|4|3|7|2|5|1|8|
|8|4|3|6|7|1|2|5|
|8|4|1|8|8|3|2|5|
|2|5|1|6|7|4|3|8|
|6|5|1|8|4|3|2|7|
|8|3|2|7|4|5|1|6|
|1|4|2|7|8|3|5|6|
|7|1|6|7|1|6|1|8|
|4|5|3|6|6|2|1|8|
|1|2|7|8|6|4|3|5|
|7|6|3|5|4|2|1|8|
|7|2|4|6|3|5|1|8|
|8|1|4|6|5|3|2|7|
|4|2|4|4|3|2|1|8|
|5|4|3|7|6|1|2|8|
|5|2|1|7|3|4|2|8|
|6|1|4|7|5|2|3|8|
|1|5|3|2|4|8|6|7|
|5|2|4|8|7|6|1|3|
|7|3|2|4|1|6|5|8|
|5|5|4|7|4|4|3|8|
|1|2|7|8|5|3|6|4|
|8|4|2|8|1|2|3|8|
|5|4|3|7|6|1|2|8|
|3|2|8|8|8|4|1|7|
|8|4|1|7|6|2|3|5|
|7|1|5|8|3|6|2|4|
|5|4|3|6|7|2|1|8|
|3|2|4|7|6|5|1|8|
|3|6|5|8|7|2|1|4|
|1|5|4|8|7|2|3|6|
|6|5|1|7|4|2|3|8|
|8|6|1|4|7|2|3|5|
|1|2|8|4|7|6|5|3|
|6|6|5|3|4|1|2|8|
|1|1|6|7|6|6|1|8|
|8|8|1|8|8|8|2|3|
|8|5|2|6|6|2|1|4|
|8|7|2|4|6|3|1|5|
|3|4|2|5|1|6|7|8|
|1|8|1|1|8|8|8|8|
|3|1|8|8|5|8|2|4|
|8|7|1|5|2|3|4|6|

#### Rank 1: PEP 8016: The Steering Council Model (Smith, Stufft) (6)
- - vs. 1 : (20 - 37)
- - vs. 2 : (22 - 40)
- - vs. 5 : (18 - 41)
- - vs. 0 : (15 - 44)
- - vs. 4 : (9 - 50)
- - vs. 3 : (6 - 55)
- - vs. 7 : (4 - 57)?

#### Rank 2: PEP 8012: The Community Governance Model (Langa) (2):
- - vs. 1 : (28 - 34)
- - vs. 5 : (22 - 33)
- - vs. 0 : (20 - 40)
- - vs. 4 : (18 - 40)
- - vs. 7 : (14 - 48)
- - vs. 3 : (9 - 48)

#### Rank 3: PEP 8011: Python Governance Model Lead by Trio of Pythonistas (Wijaya, Warsaw) (1):
- - vs. 5 : (24 - 33)
- - vs. 4 : (16 - 42)
- - vs. 0 : (14 - 42)
- - vs. 7 : (10 - 51)
- - vs. 3 : (9 - 52)
?
#### Rank 4: PEP 8015: Organization of the Python community (Stinner) (5):
- - vs. 0 : (22 - 36)
- - vs. 4 : (18 - 38)
- - vs. 3 : (12 - 47)
- - vs. 7 : (13 - 48)?

#### Rank 5: PEP 8014: The Commons Governance Model (Jansen) (4):
- - vs. 0 : (28 - 30)
- - vs. 7 : (23 - 38)
- - vs. 3 : (14 - 40)?

#### Rank 6: PEP 8010: The Technical Leader Governance Model (Warsaw) (0):
- - vs. 3 : (17 - 38)
- - vs. 7 : (18 - 43)?

#### Rank 7: PEP 8013: The External Council Governance Model (Dower) (3):
- - vs. 7 : (29 - 32)?

#### Rank 8: Further discussion (7):
- - vs. 3 : (32 - 29)?

-----BEGIN PGP SIGNATURE-----
Comment: what up, i'm ernest.

iQIzBAEBCgAdFiEEuSkpynpDar/Z/lqqTxkyLfP/otUFAlwXqjEACgkQTxkyLfP/
otXFhg//dfWINk0dficEu7iL7p/B0YwXD4JQs+uNCag/zmko5tCd4gg/wjLxe6q4
QaB7aSA84Yfrmhe4PIrm4O7doJIyqiObMxFw3N7ZbkAndOPOb2Pkk1ekAaacTTxw
lDRPR9CEPDSCtM7ahZsxu1aYHt1BWc7x8NnSyLi7IyN+bcV4viCNky9HYuTnV8i8
ed19ELFDWWlPikFjxXXr/BZA1WL/0rVgC12YtQEy9TvVhZT+kC268sYfuzOLbL6P
N2z1sbDYcilXWgH8ahCkyCrcjdySVCjd98TaTCCqCjsj4EO5gy7xf2wWujK0pDBG
rct3OESaYtIqTmsItI6P0VIHHJMeZPQ8tnQuqGIgnMMNzjXAMKEmAEvKrzu3sWIN
Vtwj3BZMGVw7ZJsuWVvSkesILPtD844R3MvLduWQ4DUuwfu4XyJV04Ws+R2TjsWE
gKoL0qk8LAgHVA3D2256wApZltPFLwksf/GaQuYSIJB8+elPOuHbCnqDSsBbEbna
LCm6RiEj0ZE6Z3rRxUFxQAwzv0Vpzj+YQFuCGtm3EGZoixJXtai7Aj1lYLI/5NOI
/Evhz9LrGN/FNQBY1tOgSIBDstkTMpUWKuIc6t1/T1WOs9iQdJmb4VQO8z0sPtwz
KeOeGBFubeb0QZg5CMV2NfhnDDCUW6ROUNzx/fTJt6ea5Ebqd8g=
=OTNq
-----END PGP SIGNATURE-----
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20181217/dfd6934d/attachment-0001.html>

From vstinner at redhat.com  Mon Dec 17 08:56:25 2018
From: vstinner at redhat.com (Victor Stinner)
Date: Mon, 17 Dec 2018 14:56:25 +0100
Subject: [python-committers] Python governance vote (December 2018):
 Results
In-Reply-To: <etPan.5c17aa3f.7778a0ed.100e2@python.org>
References: <etPan.5c17aa3f.7778a0ed.100e2@python.org>
Message-ID: <CA+3bQGGc5Ppx1n=e_Eg-WmUA5Wv-ub=6pZbhPhktrs_yjG=Veg@mail.gmail.com>

Congrats Nathaniel :-) So, what's the next step? Create a steering
council of 5 persons?

https://www.python.org/dev/peps/pep-8016/#electing-the-council

Any timeline for that?

Victor

Le lun. 17 d?c. 2018 ? 14:53, ernest at python.org <ernest at python.org> a ?crit :
>
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> # Python governance vote (December 2018)
>
> As described in [PEP 8001](https://www.python.org/dev/peps/pep-8001/), the governance election has been completed.
>
> The result is that **[PEP 8016: The Steering Council Model (Smith, Stufft)](https://www.python.org/dev/peps/pep-8016/) has been selected as the winner**.
>
> - - Supervisor: Ernest W. Durbin III <ernest at python.org>
> - - Announced end of poll: 2018-12-17T12:00:00Z
> - - Actual time poll closed: 2018-12-17T12:00:02Z
> - - Authorized voters: 94 ([CPython core developers with a known email-address](https://github.com/python/voters/blob/bb4bceda896c38177e6d9c3c2437f63a5edb23dc/2018-12-01-governance-election.csv))
> - - Actual votes cast: 62
> - - Number of winning choices: 1
> - - [Condorcet completion rule](https://civs.cs.cornell.edu/rp.html): Minimax
>
> ## Result
>
> 1. **[PEP 8016: The Steering Council Model (Smith, Stufft)](https://www.python.org/dev/peps/pep-8016/)**
>   - (Condorcet winner: wins contests with all other choices)
>
> 2. [PEP 8012: The Community Governance Model (Langa)](https://www.python.org/dev/peps/pep-8012/)
>   - loses to PEP 8016: The Steering Council Model (Smith, Stufft) by 40?22
>
> 3. [PEP 8011: Python Governance Model Lead by Trio of Pythonistas (Wijaya, Warsaw)](https://www.python.org/dev/peps/pep-8011/)
>   - loses to PEP 8016: The Steering Council Model (Smith, Stufft) by 37?20
>   - loses to PEP 8012: The Community Governance Model (Langa) by 34?28
>
> 4. [PEP 8015: Organization of the Python community (Stinner)](https://www.python.org/dev/peps/pep-8015/)
>   - loses to PEP 8016: The Steering Council Model (Smith, Stufft)by 41?18
>   - loses to PEP 8011: Python Governance Model Lead by Trio of Pythonistas (Wijaya, Warsaw) by 33?24
>
> 5. [PEP 8014: The Commons Governance Model (Jansen)](https://www.python.org/dev/peps/pep-8014/)
>   - loses to PEP 8016: The Steering Council Model (Smith, Stufft) by 50?9
>   - loses to PEP 8015: Organization of the Python community (Stinner) by 38?18
>
> 6. [PEP 8010: The Technical Leader Governance Model (Warsaw)](https://www.python.org/dev/peps/pep-8010/)
>   - loses to PEP 8016: The Steering Council Model (Smith, Stufft) by 44?15
>   - loses to PEP 8014: The Commons Governance Model (Jansen) by 30?28
>
> 7. [PEP 8013: The External Council Governance Model (Dower)](https://www.python.org/dev/peps/pep-8013/)
>   - loses to PEP 8016: The Steering Council Model (Smith, Stufft) by 55?6
>   - loses to PEP 8010: The Technical Leader Governance Model (Warsaw) by 38?17
>
> 8. Further discussion
>   - loses to PEP 8016: The Steering Council Model (Smith, Stufft) by 57?4
>   - loses to PEP 8013: The External Council Governance Model (Dower) by 32?29
>
> ### Result details
>
> |          | PEP 8016 | PEP 8012 | PEP 8011 | PEP 8015 | PEP 8014 | PEP 8010 | PEP 8013 |Discussion|
> |----------|----------|----------|----------|----------|----------|----------|----------|----------|
> | PEP 8016 | - |40 |37 |41 |50 |44 |55 |57 |
> | PEP 8012 |22 | - |34 |33 |40 |40 |48 |48 |
> | PEP 8011 |20 |28 | - |33 |42 |42 |52 |51 |
> | PEP 8015 |18 |22 |24 | - |38 |36 |47 |48 |
> | PEP 8014 | 9 |18 |16 |18 | - |30 |40 |38 |
> | PEP 8010 |15 |20 |14 |22 |28 | - |38 |43 |
> | PEP 8013 | 6 | 9 | 9 |12 |14 |17 | - |32 |
> |Discussion| 4 |14 |10 |13 |23 |18 |29 | - |
>
> ### Ballot report
>
> #### Choices
>
> - - 0. PEP 8010: The Technical Leader Governance Model (Warsaw) (changelog)
> - - 1. PEP 8011: Python Governance Model Lead by Trio of Pythonistas (Wijaya, Warsaw) (changelog
> - - 2. PEP 8012: The Community Governance Model (Langa) (changelog)
> - - 3. PEP 8013: The External Council Governance Model (Dower) (changelog)
> - - 4. PEP 8014: The Commons Governance Model (Jansen) (changelog)
> - - 5. PEP 8015: Organization of the Python community (Stinner) (changelog)
> - - 6. PEP 8016: The Steering Council Model (Smith, Stufft) (changelog)
> - - 7. Further discussion
>
> #### Ballots in randomized order
>
> |0.|1.|2.|3.|4.|5.|6.|7.|
> |---|---|---|---|---|---|---|---|
> |8|5|1|7|4|3|2|6|
> |8|3|2|4|6|5|1|7|
> |6|1|4|7|5|3|3|8|
> |3|2|7|5|4|6|1|8|
> |2|1|4|6|8|5|3|7|
> |7|2|3|6|4|7|1|5|
> |8|8|1|3|2|8|3|4|
> |6|1|2|8|4|3|5|7|
> |6|1|8|8|8|3|6|7|
> |6|1|2|7|4|3|5|8|
> |1|2|6|5|7|4|3|8|
> |1|5|7|6|3|8|2|4|
> |2|1|5|8|8|8|6|7|
> |4|4|3|2|4|4|4|1|
> |2|1|6|8|5|7|4|3|
> |4|3|8|7|6|1|2|5|
> |8|3|4|8|8|4|1|7|
> |2|1|8|6|4|7|3|5|
> |3|7|1|8|5|4|2|6|
> |6|4|3|7|2|5|1|8|
> |8|4|3|6|7|1|2|5|
> |8|4|1|8|8|3|2|5|
> |2|5|1|6|7|4|3|8|
> |6|5|1|8|4|3|2|7|
> |8|3|2|7|4|5|1|6|
> |1|4|2|7|8|3|5|6|
> |7|1|6|7|1|6|1|8|
> |4|5|3|6|6|2|1|8|
> |1|2|7|8|6|4|3|5|
> |7|6|3|5|4|2|1|8|
> |7|2|4|6|3|5|1|8|
> |8|1|4|6|5|3|2|7|
> |4|2|4|4|3|2|1|8|
> |5|4|3|7|6|1|2|8|
> |5|2|1|7|3|4|2|8|
> |6|1|4|7|5|2|3|8|
> |1|5|3|2|4|8|6|7|
> |5|2|4|8|7|6|1|3|
> |7|3|2|4|1|6|5|8|
> |5|5|4|7|4|4|3|8|
> |1|2|7|8|5|3|6|4|
> |8|4|2|8|1|2|3|8|
> |5|4|3|7|6|1|2|8|
> |3|2|8|8|8|4|1|7|
> |8|4|1|7|6|2|3|5|
> |7|1|5|8|3|6|2|4|
> |5|4|3|6|7|2|1|8|
> |3|2|4|7|6|5|1|8|
> |3|6|5|8|7|2|1|4|
> |1|5|4|8|7|2|3|6|
> |6|5|1|7|4|2|3|8|
> |8|6|1|4|7|2|3|5|
> |1|2|8|4|7|6|5|3|
> |6|6|5|3|4|1|2|8|
> |1|1|6|7|6|6|1|8|
> |8|8|1|8|8|8|2|3|
> |8|5|2|6|6|2|1|4|
> |8|7|2|4|6|3|1|5|
> |3|4|2|5|1|6|7|8|
> |1|8|1|1|8|8|8|8|
> |3|1|8|8|5|8|2|4|
> |8|7|1|5|2|3|4|6|
>
> #### Rank 1: PEP 8016: The Steering Council Model (Smith, Stufft) (6)
> - - vs. 1 : (20 - 37)
> - - vs. 2 : (22 - 40)
> - - vs. 5 : (18 - 41)
> - - vs. 0 : (15 - 44)
> - - vs. 4 : (9 - 50)
> - - vs. 3 : (6 - 55)
> - - vs. 7 : (4 - 57)
>
> #### Rank 2: PEP 8012: The Community Governance Model (Langa) (2):
> - - vs. 1 : (28 - 34)
> - - vs. 5 : (22 - 33)
> - - vs. 0 : (20 - 40)
> - - vs. 4 : (18 - 40)
> - - vs. 7 : (14 - 48)
> - - vs. 3 : (9 - 48)
>
> #### Rank 3: PEP 8011: Python Governance Model Lead by Trio of Pythonistas (Wijaya, Warsaw) (1):
> - - vs. 5 : (24 - 33)
> - - vs. 4 : (16 - 42)
> - - vs. 0 : (14 - 42)
> - - vs. 7 : (10 - 51)
> - - vs. 3 : (9 - 52)
>
> #### Rank 4: PEP 8015: Organization of the Python community (Stinner) (5):
> - - vs. 0 : (22 - 36)
> - - vs. 4 : (18 - 38)
> - - vs. 3 : (12 - 47)
> - - vs. 7 : (13 - 48)
>
> #### Rank 5: PEP 8014: The Commons Governance Model (Jansen) (4):
> - - vs. 0 : (28 - 30)
> - - vs. 7 : (23 - 38)
> - - vs. 3 : (14 - 40)
>
> #### Rank 6: PEP 8010: The Technical Leader Governance Model (Warsaw) (0):
> - - vs. 3 : (17 - 38)
> - - vs. 7 : (18 - 43)
>
> #### Rank 7: PEP 8013: The External Council Governance Model (Dower) (3):
> - - vs. 7 : (29 - 32)
>
> #### Rank 8: Further discussion (7):
> - - vs. 3 : (32 - 29)
>
> -----BEGIN PGP SIGNATURE-----
> Comment: what up, i'm ernest.
>
> iQIzBAEBCgAdFiEEuSkpynpDar/Z/lqqTxkyLfP/otUFAlwXqjEACgkQTxkyLfP/
> otXFhg//dfWINk0dficEu7iL7p/B0YwXD4JQs+uNCag/zmko5tCd4gg/wjLxe6q4
> QaB7aSA84Yfrmhe4PIrm4O7doJIyqiObMxFw3N7ZbkAndOPOb2Pkk1ekAaacTTxw
> lDRPR9CEPDSCtM7ahZsxu1aYHt1BWc7x8NnSyLi7IyN+bcV4viCNky9HYuTnV8i8
> ed19ELFDWWlPikFjxXXr/BZA1WL/0rVgC12YtQEy9TvVhZT+kC268sYfuzOLbL6P
> N2z1sbDYcilXWgH8ahCkyCrcjdySVCjd98TaTCCqCjsj4EO5gy7xf2wWujK0pDBG
> rct3OESaYtIqTmsItI6P0VIHHJMeZPQ8tnQuqGIgnMMNzjXAMKEmAEvKrzu3sWIN
> Vtwj3BZMGVw7ZJsuWVvSkesILPtD844R3MvLduWQ4DUuwfu4XyJV04Ws+R2TjsWE
> gKoL0qk8LAgHVA3D2256wApZltPFLwksf/GaQuYSIJB8+elPOuHbCnqDSsBbEbna
> LCm6RiEj0ZE6Z3rRxUFxQAwzv0Vpzj+YQFuCGtm3EGZoixJXtai7Aj1lYLI/5NOI
> /Evhz9LrGN/FNQBY1tOgSIBDstkTMpUWKuIc6t1/T1WOs9iQdJmb4VQO8z0sPtwz
> KeOeGBFubeb0QZg5CMV2NfhnDDCUW6ROUNzx/fTJt6ea5Ebqd8g=
> =OTNq
> -----END PGP SIGNATURE-----
> _______________________________________________
> 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/



-- 
Night gathers, and now my watch begins. It shall not end until my death.

From ernest at python.org  Mon Dec 17 09:16:52 2018
From: ernest at python.org (=?utf-8?Q?ernest=40python.org?=)
Date: Mon, 17 Dec 2018 09:16:52 -0500
Subject: [python-committers] Python governance vote (December 2018):
 Results
In-Reply-To: <etPan.5c17aa3f.7778a0ed.100e2@python.org>
References: <etPan.5c17aa3f.7778a0ed.100e2@python.org>
Message-ID: <etPan.5c17afd4.79743054.100e2@python.org>

Full results are also auditable directly at?https://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_fe2b74aea628b45d

-Ernest W. Durbin III
On December 17, 2018 at 8:53:04 AM, ernest at python.org (ernest at python.org) wrote:


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

# Python governance vote (December 2018)

As described in [PEP 8001](https://www.python.org/dev/peps/pep-8001/), the governance election has been completed.

The result is that **[PEP 8016: The Steering Council Model (Smith, Stufft)](https://www.python.org/dev/peps/pep-8016/) has been selected as the winner**.

- - Supervisor: Ernest W. Durbin III <ernest at python.org>
- - Announced end of poll: 2018-12-17T12:00:00Z
- - Actual time poll closed: 2018-12-17T12:00:02Z
- - Authorized voters: 94 ([CPython core developers with a known email-address](https://github.com/python/voters/blob/bb4bceda896c38177e6d9c3c2437f63a5edb23dc/2018-12-01-governance-election.csv))
- - Actual votes cast: 62
- - Number of winning choices: 1
- - [Condorcet completion rule](https://civs.cs.cornell.edu/rp.html): Minimax

## Result

1. **[PEP 8016: The Steering Council Model (Smith, Stufft)](https://www.python.org/dev/peps/pep-8016/)**
? - (Condorcet winner: wins contests with all other choices)

2. [PEP 8012: The Community Governance Model (Langa)](https://www.python.org/dev/peps/pep-8012/)
? - loses to PEP 8016: The Steering Council Model (Smith, Stufft) by 40?22

3. [PEP 8011: Python Governance Model Lead by Trio of Pythonistas (Wijaya, Warsaw)](https://www.python.org/dev/peps/pep-8011/)
? - loses to PEP 8016: The Steering Council Model (Smith, Stufft) by 37?20
? - loses to PEP 8012: The Community Governance Model (Langa) by 34?28

4. [PEP 8015: Organization of the Python community (Stinner)](https://www.python.org/dev/peps/pep-8015/)
? - loses to PEP 8016: The Steering Council Model (Smith, Stufft)by 41?18
? - loses to PEP 8011: Python Governance Model Lead by Trio of Pythonistas (Wijaya, Warsaw) by 33?24

5. [PEP 8014: The Commons Governance Model (Jansen)](https://www.python.org/dev/peps/pep-8014/)
? - loses to PEP 8016: The Steering Council Model (Smith, Stufft) by 50?9
? - loses to PEP 8015: Organization of the Python community (Stinner) by 38?18

6. [PEP 8010: The Technical Leader Governance Model (Warsaw)](https://www.python.org/dev/peps/pep-8010/)
? - loses to PEP 8016: The Steering Council Model (Smith, Stufft) by 44?15
? - loses to PEP 8014: The Commons Governance Model (Jansen) by 30?28

7. [PEP 8013: The External Council Governance Model (Dower)](https://www.python.org/dev/peps/pep-8013/)
? - loses to PEP 8016: The Steering Council Model (Smith, Stufft) by 55?6
? - loses to PEP 8010: The Technical Leader Governance Model (Warsaw) by 38?17

8. Further discussion
? - loses to PEP 8016: The Steering Council Model (Smith, Stufft) by 57?4
? - loses to PEP 8013: The External Council Governance Model (Dower) by 32?29

### Result details

| ? ? ? ? ?| PEP 8016 | PEP 8012 | PEP 8011 | PEP 8015 | PEP 8014 | PEP 8010 | PEP 8013 |Discussion|
|----------|----------|----------|----------|----------|----------|----------|----------|----------|
| PEP 8016 | - |40 |37 |41 |50 |44 |55 |57 |
| PEP 8012 |22 | - |34 |33 |40 |40 |48 |48 |
| PEP 8011 |20 |28 | - |33 |42 |42 |52 |51 |
| PEP 8015 |18 |22 |24 | - |38 |36 |47 |48 |
| PEP 8014 | 9 |18 |16 |18 | - |30 |40 |38 |
| PEP 8010 |15 |20 |14 |22 |28 | - |38 |43 |
| PEP 8013 | 6 | 9 | 9 |12 |14 |17 | - |32 |
|Discussion| 4 |14 |10 |13 |23 |18 |29 | - |

### Ballot report

#### Choices

- - 0. PEP 8010: The Technical Leader Governance Model (Warsaw) (changelog)
- - 1. PEP 8011: Python Governance Model Lead by Trio of Pythonistas (Wijaya, Warsaw) (changelog
- - 2. PEP 8012: The Community Governance Model (Langa) (changelog)
- - 3. PEP 8013: The External Council Governance Model (Dower) (changelog)
- - 4. PEP 8014: The Commons Governance Model (Jansen) (changelog)
- - 5. PEP 8015: Organization of the Python community (Stinner) (changelog)
- - 6. PEP 8016: The Steering Council Model (Smith, Stufft) (changelog)
- - 7. Further discussion

#### Ballots in randomized order

|0.|1.|2.|3.|4.|5.|6.|7.|
|---|---|---|---|---|---|---|---|
|8|5|1|7|4|3|2|6|
|8|3|2|4|6|5|1|7|
|6|1|4|7|5|3|3|8|
|3|2|7|5|4|6|1|8|
|2|1|4|6|8|5|3|7|
|7|2|3|6|4|7|1|5|
|8|8|1|3|2|8|3|4|
|6|1|2|8|4|3|5|7|
|6|1|8|8|8|3|6|7|
|6|1|2|7|4|3|5|8|
|1|2|6|5|7|4|3|8|
|1|5|7|6|3|8|2|4|
|2|1|5|8|8|8|6|7|
|4|4|3|2|4|4|4|1|
|2|1|6|8|5|7|4|3|
|4|3|8|7|6|1|2|5|
|8|3|4|8|8|4|1|7|
|2|1|8|6|4|7|3|5|
|3|7|1|8|5|4|2|6|
|6|4|3|7|2|5|1|8|
|8|4|3|6|7|1|2|5|
|8|4|1|8|8|3|2|5|
|2|5|1|6|7|4|3|8|
|6|5|1|8|4|3|2|7|
|8|3|2|7|4|5|1|6|
|1|4|2|7|8|3|5|6|
|7|1|6|7|1|6|1|8|
|4|5|3|6|6|2|1|8|
|1|2|7|8|6|4|3|5|
|7|6|3|5|4|2|1|8|
|7|2|4|6|3|5|1|8|
|8|1|4|6|5|3|2|7|
|4|2|4|4|3|2|1|8|
|5|4|3|7|6|1|2|8|
|5|2|1|7|3|4|2|8|
|6|1|4|7|5|2|3|8|
|1|5|3|2|4|8|6|7|
|5|2|4|8|7|6|1|3|
|7|3|2|4|1|6|5|8|
|5|5|4|7|4|4|3|8|
|1|2|7|8|5|3|6|4|
|8|4|2|8|1|2|3|8|
|5|4|3|7|6|1|2|8|
|3|2|8|8|8|4|1|7|
|8|4|1|7|6|2|3|5|
|7|1|5|8|3|6|2|4|
|5|4|3|6|7|2|1|8|
|3|2|4|7|6|5|1|8|
|3|6|5|8|7|2|1|4|
|1|5|4|8|7|2|3|6|
|6|5|1|7|4|2|3|8|
|8|6|1|4|7|2|3|5|
|1|2|8|4|7|6|5|3|
|6|6|5|3|4|1|2|8|
|1|1|6|7|6|6|1|8|
|8|8|1|8|8|8|2|3|
|8|5|2|6|6|2|1|4|
|8|7|2|4|6|3|1|5|
|3|4|2|5|1|6|7|8|
|1|8|1|1|8|8|8|8|
|3|1|8|8|5|8|2|4|
|8|7|1|5|2|3|4|6|

#### Rank 1: PEP 8016: The Steering Council Model (Smith, Stufft) (6)
- - vs. 1 : (20 - 37)
- - vs. 2 : (22 - 40)
- - vs. 5 : (18 - 41)
- - vs. 0 : (15 - 44)
- - vs. 4 : (9 - 50)
- - vs. 3 : (6 - 55)
- - vs. 7 : (4 - 57)?

#### Rank 2: PEP 8012: The Community Governance Model (Langa) (2):
- - vs. 1 : (28 - 34)
- - vs. 5 : (22 - 33)
- - vs. 0 : (20 - 40)
- - vs. 4 : (18 - 40)
- - vs. 7 : (14 - 48)
- - vs. 3 : (9 - 48)

#### Rank 3: PEP 8011: Python Governance Model Lead by Trio of Pythonistas (Wijaya, Warsaw) (1):
- - vs. 5 : (24 - 33)
- - vs. 4 : (16 - 42)
- - vs. 0 : (14 - 42)
- - vs. 7 : (10 - 51)
- - vs. 3 : (9 - 52)
?
#### Rank 4: PEP 8015: Organization of the Python community (Stinner) (5):
- - vs. 0 : (22 - 36)
- - vs. 4 : (18 - 38)
- - vs. 3 : (12 - 47)
- - vs. 7 : (13 - 48)?

#### Rank 5: PEP 8014: The Commons Governance Model (Jansen) (4):
- - vs. 0 : (28 - 30)
- - vs. 7 : (23 - 38)
- - vs. 3 : (14 - 40)?

#### Rank 6: PEP 8010: The Technical Leader Governance Model (Warsaw) (0):
- - vs. 3 : (17 - 38)
- - vs. 7 : (18 - 43)?

#### Rank 7: PEP 8013: The External Council Governance Model (Dower) (3):
- - vs. 7 : (29 - 32)?

#### Rank 8: Further discussion (7):
- - vs. 3 : (32 - 29)?

-----BEGIN PGP SIGNATURE-----
Comment: what up, i'm ernest.

iQIzBAEBCgAdFiEEuSkpynpDar/Z/lqqTxkyLfP/otUFAlwXqjEACgkQTxkyLfP/
otXFhg//dfWINk0dficEu7iL7p/B0YwXD4JQs+uNCag/zmko5tCd4gg/wjLxe6q4
QaB7aSA84Yfrmhe4PIrm4O7doJIyqiObMxFw3N7ZbkAndOPOb2Pkk1ekAaacTTxw
lDRPR9CEPDSCtM7ahZsxu1aYHt1BWc7x8NnSyLi7IyN+bcV4viCNky9HYuTnV8i8
ed19ELFDWWlPikFjxXXr/BZA1WL/0rVgC12YtQEy9TvVhZT+kC268sYfuzOLbL6P
N2z1sbDYcilXWgH8ahCkyCrcjdySVCjd98TaTCCqCjsj4EO5gy7xf2wWujK0pDBG
rct3OESaYtIqTmsItI6P0VIHHJMeZPQ8tnQuqGIgnMMNzjXAMKEmAEvKrzu3sWIN
Vtwj3BZMGVw7ZJsuWVvSkesILPtD844R3MvLduWQ4DUuwfu4XyJV04Ws+R2TjsWE
gKoL0qk8LAgHVA3D2256wApZltPFLwksf/GaQuYSIJB8+elPOuHbCnqDSsBbEbna
LCm6RiEj0ZE6Z3rRxUFxQAwzv0Vpzj+YQFuCGtm3EGZoixJXtai7Aj1lYLI/5NOI
/Evhz9LrGN/FNQBY1tOgSIBDstkTMpUWKuIc6t1/T1WOs9iQdJmb4VQO8z0sPtwz
KeOeGBFubeb0QZg5CMV2NfhnDDCUW6ROUNzx/fTJt6ea5Ebqd8g=
=OTNq
-----END PGP SIGNATURE-----
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20181217/951aa4da/attachment-0001.html>

From andrew.svetlov at gmail.com  Mon Dec 17 09:26:23 2018
From: andrew.svetlov at gmail.com (Andrew Svetlov)
Date: Mon, 17 Dec 2018 16:26:23 +0200
Subject: [python-committers] Licences for PyCharm and other JetBrains
 products
In-Reply-To: <1420954884.1881529.1512750799609@mail.yahoo.com>
References: <1420954884.1881529.1512750799609.ref@mail.yahoo.com>
 <1420954884.1881529.1512750799609@mail.yahoo.com>
Message-ID: <CAL3CFcV6P4C4_ZJRVccbkWC6gkS-FRk3zWqVy+ZkbDDGwr2LbA@mail.gmail.com>

Vinaj, hi.

Could I get a PyCharm license?

On Fri, Dec 8, 2017 at 6:33 PM Vinay Sajip via python-committers <
python-committers at python.org> wrote:

> Recently I received 20 one-year licenses from JetBrains for the PyCharm
> IDE (Professional) and other JetBrains products (the licenses cover their
> "All Products Pack") for use in Python development. There are 11 licenses
> available - of the licenses I asked for last year, nine people took them
> up, so those are in use and come out of the allocation of 20.
>
> Those of you who took up the licences last time should find that the tools
> continue to work normally. The licences expire on 27 November 2018.
>
> If any others of you are interested in using these licenses, let me know
> off-list and I will forward the license access details to you. To access
> the licenses, you will need to have (or create) a JetBrains account.
>
> Regards,
>
> Vinay Sajip
> _______________________________________________
> 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/
>


-- 
Thanks,
Andrew Svetlov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20181217/10557436/attachment.html>

From vstinner at redhat.com  Wed Dec 19 09:01:08 2018
From: vstinner at redhat.com (Victor Stinner)
Date: Wed, 19 Dec 2018 15:01:08 +0100
Subject: [python-committers] [Python-Dev] 3.7.2rc1 and 3.6.8rc1 cutoffs
 ahead, last 3.6.x bugfix release!
In-Reply-To: <1109428671.99278808.1545215281839.JavaMail.zimbra@redhat.com>
References: <95B9F244-38A8-4E47-8E9D-6DAD289C84A2@python.org>
 <033423e6-5918-24e1-c5a5-daf829a3e1ef@gmail.com>
 <1109428671.99278808.1545215281839.JavaMail.zimbra@redhat.com>
Message-ID: <CA+3bQGFRTqttLCRU-5TfKRWpoTpBGXhe3i8oGu4DoVdtPo6aPA@mail.gmail.com>

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.

From storchaka at gmail.com  Wed Dec 19 09:43:42 2018
From: storchaka at gmail.com (Serhiy Storchaka)
Date: Wed, 19 Dec 2018 16:43:42 +0200
Subject: [python-committers] [Python-Dev] 3.7.2rc1 and 3.6.8rc1 cutoffs
 ahead, last 3.6.x bugfix release!
In-Reply-To: <CA+3bQGFRTqttLCRU-5TfKRWpoTpBGXhe3i8oGu4DoVdtPo6aPA@mail.gmail.com>
References: <95B9F244-38A8-4E47-8E9D-6DAD289C84A2@python.org>
 <033423e6-5918-24e1-c5a5-daf829a3e1ef@gmail.com>
 <1109428671.99278808.1545215281839.JavaMail.zimbra@redhat.com>
 <CA+3bQGFRTqttLCRU-5TfKRWpoTpBGXhe3i8oGu4DoVdtPo6aPA@mail.gmail.com>
Message-ID: <pvdlas$8hi$1@blaine.gmane.org>

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.


From brett at python.org  Wed Dec 19 12:43:35 2018
From: brett at python.org (Brett Cannon)
Date: Wed, 19 Dec 2018 09:43:35 -0800
Subject: [python-committers] [Python-Dev] 3.7.2rc1 and 3.6.8rc1 cutoffs
 ahead, last 3.6.x bugfix release!
In-Reply-To: <CA+3bQGFRTqttLCRU-5TfKRWpoTpBGXhe3i8oGu4DoVdtPo6aPA@mail.gmail.com>
References: <95B9F244-38A8-4E47-8E9D-6DAD289C84A2@python.org>
 <033423e6-5918-24e1-c5a5-daf829a3e1ef@gmail.com>
 <1109428671.99278808.1545215281839.JavaMail.zimbra@redhat.com>
 <CA+3bQGFRTqttLCRU-5TfKRWpoTpBGXhe3i8oGu4DoVdtPo6aPA@mail.gmail.com>
Message-ID: <CAP1=2W73+-KUwQG9-LFTz3Xu+mnQsyOd0=sUyyKRJ-yATcQaew@mail.gmail.com>

[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 <vstinner at redhat.com> 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!" ;) .
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20181219/1900d414/attachment.html>

From greg at krypto.org  Wed Dec 19 13:24:09 2018
From: greg at krypto.org (Gregory P. Smith)
Date: Wed, 19 Dec 2018 10:24:09 -0800
Subject: [python-committers] [Python-Dev] 3.7.2rc1 and 3.6.8rc1 cutoffs
 ahead, last 3.6.x bugfix release!
In-Reply-To: <CAP1=2W73+-KUwQG9-LFTz3Xu+mnQsyOd0=sUyyKRJ-yATcQaew@mail.gmail.com>
References: <95B9F244-38A8-4E47-8E9D-6DAD289C84A2@python.org>
 <033423e6-5918-24e1-c5a5-daf829a3e1ef@gmail.com>
 <1109428671.99278808.1545215281839.JavaMail.zimbra@redhat.com>
 <CA+3bQGFRTqttLCRU-5TfKRWpoTpBGXhe3i8oGu4DoVdtPo6aPA@mail.gmail.com>
 <CAP1=2W73+-KUwQG9-LFTz3Xu+mnQsyOd0=sUyyKRJ-yATcQaew@mail.gmail.com>
Message-ID: <CAGE7PNJLs_NcZrwXXqDkK+YYyGkEuUHkjVHZ+OFi5+_na3jYwg@mail.gmail.com>

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 <brett at python.org> 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 <vstinner at redhat.com> 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 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/20181219/1d9300e3/attachment-0001.html>

From nad at python.org  Wed Dec 19 14:38:45 2018
From: nad at python.org (Ned Deily)
Date: Wed, 19 Dec 2018 14:38:45 -0500
Subject: [python-committers] Extending 3.6 [was: 3.7.2rc1 and 3.6.8rc1
 cutoffs ahead, last 3.6.x bugfix release!]
In-Reply-To: <CAGE7PNJLs_NcZrwXXqDkK+YYyGkEuUHkjVHZ+OFi5+_na3jYwg@mail.gmail.com>
References: <95B9F244-38A8-4E47-8E9D-6DAD289C84A2@python.org>
 <033423e6-5918-24e1-c5a5-daf829a3e1ef@gmail.com>
 <1109428671.99278808.1545215281839.JavaMail.zimbra@redhat.com>
 <CA+3bQGFRTqttLCRU-5TfKRWpoTpBGXhe3i8oGu4DoVdtPo6aPA@mail.gmail.com>
 <CAP1=2W73+-KUwQG9-LFTz3Xu+mnQsyOd0=sUyyKRJ-yATcQaew@mail.gmail.com>
 <CAGE7PNJLs_NcZrwXXqDkK+YYyGkEuUHkjVHZ+OFi5+_na3jYwg@mail.gmail.com>
Message-ID: <E4529CD5-74DE-4462-A17A-952BAF1C85EA@python.org>

On Dec 19, 2018, at 04:14, Serhiy Storchaka <storchaka at 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 at 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 at python.org -- []


From brett at python.org  Fri Dec 21 14:22:51 2018
From: brett at python.org (Brett Cannon)
Date: Fri, 21 Dec 2018 11:22:51 -0800
Subject: [python-committers] Poll to choose a voting timeline for the
 steering council
Message-ID: <CAP1=2W6K0sf0HNwb+FMPBK-qJMpvtn+JO2d_6kip46BP9pzUvQ@mail.gmail.com>

I didn't put a close date on the poll, but obviously the sooner we can
resolve this the easier it will be to schedule stuff if the earlier date
gets chosen.

https://discuss.python.org/t/vote-on-possible-steering-council-election-timelines/580
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20181221/cc11c7e2/attachment.html>

From ncoghlan at gmail.com  Sat Dec 22 20:08:27 2018
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 23 Dec 2018 11:08:27 +1000
Subject: [python-committers] [Python-Dev] 3.7.2rc1 and 3.6.8rc1 cutoffs
 ahead, last 3.6.x bugfix release!
In-Reply-To: <CAP1=2W73+-KUwQG9-LFTz3Xu+mnQsyOd0=sUyyKRJ-yATcQaew@mail.gmail.com>
References: <95B9F244-38A8-4E47-8E9D-6DAD289C84A2@python.org>
 <033423e6-5918-24e1-c5a5-daf829a3e1ef@gmail.com>
 <1109428671.99278808.1545215281839.JavaMail.zimbra@redhat.com>
 <CA+3bQGFRTqttLCRU-5TfKRWpoTpBGXhe3i8oGu4DoVdtPo6aPA@mail.gmail.com>
 <CAP1=2W73+-KUwQG9-LFTz3Xu+mnQsyOd0=sUyyKRJ-yATcQaew@mail.gmail.com>
Message-ID: <CADiSq7dPDKY8BevMynJrcj59hn54OMuS+YmJSTzmnXib5Mmszg@mail.gmail.com>

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

>
> On Wed, 19 Dec 2018 at 06:01, Victor Stinner <vstinner at 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).

Cheers,
Nick.



>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20181223/17818de0/attachment.html>

From nad at python.org  Mon Dec 24 06:57:53 2018
From: nad at python.org (Ned Deily)
Date: Mon, 24 Dec 2018 06:57:53 -0500
Subject: [python-committers] [RELEASE] Python 3.7.2 and 3.6.8 are now
 available
Message-ID: <3041C039-C5F6-4A01-BEB8-783238B07970@python.org>

https://blog.python.org/2018/12/python-372-and-368-are-now-available.html

Python 3.7.2 and 3.6.8 are now available. Python 3.7.2 is the next
maintenance release of Python 3.7, the latest feature release of Python.
You can find Python 3.7.2 here:
    https://www.python.org/downloads/release/python-372/

See the What?s New In Python 3.7 document for more information about the
many new features and optimizations included in the 3.7 series. Detailed
information about the changes made in 3.7.2 can be found in its change log.

We are also happy to announce the availability of Python 3.6.8:
    https://www.python.org/downloads/release/python-368/

Python 3.6.8 is planned to be the last bugfix release of Python 3.6. Per
our support policy, we plan to provide security fixes for Python 3.6 as
needed through 2021, five years following its initial release.

Thanks to all of the many volunteers who help make Python Development and
these releases possible! Please consider supporting our efforts by
volunteering yourself or through organization contributions to the Python
Software Foundation.

https://docs.python.org/3.7/whatsnew/3.7.html
https://docs.python.org/3.7/whatsnew/changelog.html#python-3-7-2-final
https://docs.python.org/3.6/whatsnew/changelog.html#python-3-6-8-final
https://www.python.org/psf/

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


From encukou at gmail.com  Sat Dec 29 08:09:18 2018
From: encukou at gmail.com (Petr Viktorin)
Date: Sat, 29 Dec 2018 14:09:18 +0100
Subject: [python-committers] [Python-Dev] 3.7.2rc1 and 3.6.8rc1 cutoffs
 ahead, last 3.6.x bugfix release!
In-Reply-To: <CADiSq7dPDKY8BevMynJrcj59hn54OMuS+YmJSTzmnXib5Mmszg@mail.gmail.com>
References: <95B9F244-38A8-4E47-8E9D-6DAD289C84A2@python.org>
 <033423e6-5918-24e1-c5a5-daf829a3e1ef@gmail.com>
 <1109428671.99278808.1545215281839.JavaMail.zimbra@redhat.com>
 <CA+3bQGFRTqttLCRU-5TfKRWpoTpBGXhe3i8oGu4DoVdtPo6aPA@mail.gmail.com>
 <CAP1=2W73+-KUwQG9-LFTz3Xu+mnQsyOd0=sUyyKRJ-yATcQaew@mail.gmail.com>
 <CADiSq7dPDKY8BevMynJrcj59hn54OMuS+YmJSTzmnXib5Mmszg@mail.gmail.com>
Message-ID: <76a65d63-0b05-a47e-e6c7-5f9771aa771c@gmail.com>

On 12/23/18 2:08 AM, Nick Coghlan wrote:
> On Thu., 20 Dec. 2018, 3:46 am Brett Cannon <brett at python.org 
> <mailto:brett at python.org> wrote:
> 
> 
>     On Wed, 19 Dec 2018 at 06:01, Victor Stinner <vstinner at redhat.com
>     <mailto:vstinner at 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.