[Tim] >>>>> > hg log -r 3.2 >>>>> changeset: 83826:b9b521efeba3 >>>>> branch: 3.2 >>>>> parent: 83739:6255b40c6a61 >>>>> user: Antoine Pitrou <solip...@pitrou.net> >>>>> date: Sat May 18 17:56:42 2013 +0200 >>>>> summary: Issue #17980: Fix possible abuse of ssl.match_hostname() >>>>> for denial of service using certificates with many wildcards >>>>> (CVE-2013-2099).
[Antoine] >>>> Oops, that's me :-S >>>> Now I don't remember if I omitted to merge deliberately, or if that was >>>> an oversight. [Tim] >>> Well, yours is just the tip of the 3.2 branch. 3.2 was already active >>> when you made this commit, left over from the 3.2.5 release fiddling >>> (when, presumably, a merge to default was also skipped): [R. David Murray] >> Georg indicated at the time that not merging was intentional. [Antoine] > Ah, now I remember indeed: > http://mail.python.org/pipermail/python-committers/2013-May/002580.html Which says: I asked about this on IRC and was told that 3.2 is now a standalone branch like 2.7. Security fixes will be applied by the release manager only, and Georg doesn't see any point in null merging the commits. Isn't the point exactly the same as for all other "old-to-new branch" null merges? That is, 1. So that 3.2 doesn't show up as an active branch under "hg branches"; and, 2. So that security fixes applied to the 3.2 branch can be easily forward-ported to the 3.3 and default branches via no-hassle merges. What is gained by _not_ merging here? I don't see it. I suppose the answer, as to everything else, lies in "hg strip" <wink>. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
