Re: [Python-Dev] [Python-checkins] cpython (2.7): Issue #13156: revert changeset f6feed6ec3f9, which was only relevant for native
Le mercredi 12 octobre 2011 21:07:33, charles-francois.natali a écrit :
changeset: 72897:ee4fe16d9b48 branch: 2.7 parent: 69635:f6feed6ec3f9 user: Charles-François Natali <neologix@free.fr> date: Wed Oct 12 21:07:54 2011 +0200 summary: Issue #13156: revert changeset f6feed6ec3f9, which was only relevant for native TLS implementations, and fails with the ad-hoc TLS implementation when a thread doesn't have an auto thread state (e.g. a thread created outside of Python calling into a subinterpreter).
--- a/Misc/NEWS +++ b/Misc/NEWS @@ -61,10 +61,6 @@ Library -------
-- Issue #10517: After fork(), reinitialize the TLS used by the PyGILState_* - APIs, to avoid a crash with the pthread implementation in RHEL 5. Patch - by Charles-François Natali.
You should restore this NEWS entry and add a new one to say that the patch has been reverted. Victor
-- Issue #10517: After fork(), reinitialize the TLS used by the PyGILState_* - APIs, to avoid a crash with the pthread implementation in RHEL 5. Patch - by Charles-François Natali.
You should restore this NEWS entry and add a new one to say that the patch has been reverted.
This may be a done deal, but: no. If a patch is reverted, the NEWS entry that got in with it gets out again on reversal. The NEWS file is for users of the release; there is no point telling them that a change was made first, and than got undone. Regards, Martin
On 10/15/2011 7:47 AM, "Martin v. Löwis" wrote:
-- Issue #10517: After fork(), reinitialize the TLS used by the PyGILState_* - APIs, to avoid a crash with the pthread implementation in RHEL 5. Patch - by Charles-François Natali.
You should restore this NEWS entry and add a new one to say that the patch has been reverted.
This may be a done deal, but: no. If a patch is reverted, the NEWS entry that got in with it gets out again on reversal. The NEWS file is for users of the release; there is no point telling them that a change was made first, and than got undone.
I was going to say the same thing, but ... If a change is released in x.y.z and reverted for release x.y.(z+k), then I think both notices should be present in their respective sections. I checked the date on the original patch and it was before 3.2.1, so perhaps it *was* released. -- Terry Jan Reedy
On Sun, Oct 16, 2011 at 6:10 AM, Terry Reedy <tjreedy@udel.edu> wrote:
On 10/15/2011 7:47 AM, "Martin v. Löwis" wrote:
This may be a done deal, but: no. If a patch is reverted, the NEWS entry that got in with it gets out again on reversal. The NEWS file is for users of the release; there is no point telling them that a change was made first, and than got undone.
I was going to say the same thing, but ...
If a change is released in x.y.z and reverted for release x.y.(z+k), then I think both notices should be present in their respective sections.
I checked the date on the original patch and it was before 3.2.1, so perhaps it *was* released.
Indeed, "was it released?" is the gating criteria for whether the old NEWS entry is removed or whether a new one is made. No release should ever remove a NEWS entry from an earlier release, *unless* the NEWS entry itself was a mistake (i.e. it refers to a change that wasn't actually part of a release). Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
participants (4)
-
"Martin v. Löwis" -
Nick Coghlan -
Terry Reedy -
Victor Stinner