Author ncoghlan
Recipients Arfrever, alex, benjamin.peterson, christian.heimes, dstufft, geertj, giampaolo.rodola, janssen, ncoghlan, pitrou, vstinner
Date 2015-09-20.11:38:40
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1442749120.38.0.396843827504.issue22559@psf.upfronthosting.co.za>
In-reply-to
Content
Guido specifically asked for a new PEP for each resync that explicitly enumerated the changes being backported, after earlier drafts of PEP 466 requested blanket future permission for network security related backports.

That approach actually turns out to be better from a documentation and backport management perspective - I organised the "New features in maintenance releases" section of the Python 2.7 What's New by PEP number, and "we backported PEP 466" nicely describes the changes that were backport to RHEL 7.2.

A new PEP for resyncing with Python 3.5 can be a lot simpler than PEP 466 was, though - the basic rationale doesn't need to be repeated, and the PEP 466 backport already brought the implementations much closer together.
History
Date User Action Args
2015-09-20 11:38:40ncoghlansetrecipients: + ncoghlan, geertj, janssen, pitrou, vstinner, giampaolo.rodola, christian.heimes, benjamin.peterson, Arfrever, alex, dstufft
2015-09-20 11:38:40ncoghlansetmessageid: <1442749120.38.0.396843827504.issue22559@psf.upfronthosting.co.za>
2015-09-20 11:38:40ncoghlanlinkissue22559 messages
2015-09-20 11:38:40ncoghlancreate