[Tim]

...

...

hg log -r 3.2 changeset: 83826:b9b521efeba3 branch: 3.2 parent: 83739:6255b40c6a61 user: Antoine Pitrou 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.

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

hg log -v -r "children(ancestor(3.2, default)):: and branch(3.2)" changeset: 83738:cef745775b65 branch: 3.2 tag: v3.2.5 user: Georg Brandl date: Sun May 12 12:28:20 2013 +0200 files: Include/patchlevel.h Lib/distutils/__init__.py Lib/idlelib/idlever.py Misc/NEWS Misc/RPM/python-3.2.spec README description: Bump to version 3.2.5.

changeset: 83739:6255b40c6a61 branch: 3.2 user: Georg Brandl date: Sun May 12 12:28:30 2013 +0200 files: .hgtags description: Added tag v3.2.5 for changeset cef745775b65 changeset: 83826:b9b521efeba3 branch: 3.2 parent: 83739:6255b40c6a61 user: Antoine Pitrou date: Sat May 18 17:56:42 2013 +0200 files: Lib/ssl.py Lib/test/test_ssl.py Misc/NEWS description: Issue #17980: Fix possible abuse of ssl.match_hostname() for denial of service using certificates with many wi ldcards (CVE-2013-2099).

For the record, the issue was fixed in 3.3 too, albeit not with a merge changeset.

In that case, I bet this one is easy to fix, for someone who knows what they're doing ;-)

On Tue, 20 Aug 2013 13:16:05 -0400 "R. David Murray" wrote:

On Tue, 20 Aug 2013 10:43:57 -0500, Tim Peters wrote:

...

[Tim]

...

...

...

hg log -r 3.2 changeset: 83826:b9b521efeba3 branch: 3.2 parent: 83739:6255b40c6a61 user: Antoine Pitrou 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.

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

Georg indicated at the time that not merging was intentional.

Ah, now I remember indeed: http://mail.python.org/pipermail/python-committers/2013-May/002580.html Thanks Antoine.

On Tue, 20 Aug 2013 12:47:46 -0500 Tim Peters wrote:

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

Perhaps Georg doesn't like merges? ;-) I suppose what's gained is "one less command to type". Regards Antoine.

On Aug 20, 2013, at 07:33 PM, Tim Peters wrote:

So let's try a different question ;-) Would anyone _object_ to completing the process described in the docs: merge 3.2 into 3.3, then merge 3.3 into default? I'd be happy to do that. I'd throw away all the merge changes except for adding the v3,2.5 tag to .hgtags.

The only active branches remaining would be `default` and 2.7, which is what I expected when I started this ;-)

That's what I'd expect to, so no objections from me. But I'm only the lowly 2.6 RM and I will soon be rid of that particular albatross! FWIW, I'm still merging relevant 2.6 changes into 2.7 (or null merging them if not relevant). Oh, and welcome back Uncle Timmy! (If that's you're real name.) -Barry

[Tim, wondering why the 3.2 branch isn't "inactive"]

...

... So let's try a different question ;-) Would anyone _object_ to completing the process described in the docs: merge 3.2 into 3.3, then merge 3.3 into default? I'd be happy to do that. I'd throw away all the merge changes except for adding the v3,2.5 tag to .hgtags.

The only active branches remaining would be `default` and 2.7, which is what I expected when I started this ;-)

[Brett Cannon]

While I would think Georg can object if he wants, I see no reason to help visibly shutter the 3.2 branch by doing null merges. It isn't like it makes using hg harder or the history harder to read.

Well, why do we _ever_ do a null merge? Then why don't the reasons apply in this case? What happened here doesn't match the documented workflow - so one or the other should be changed. It has proved tedious to find out why this exception exists, and the only reason I've found so far amounts to "the RM didn't want to bother -- and the only record of that is someone's memory of an IRC chat". As mentioned before, if a security hole is found in 3.2 and gets repaired there, the poor soul who fixes 3.2 will have all the same questions when they try to forward-merge the fix to 3.3 and default. Because the merge wasn't done when 3.2.5 was released, they'll have a pile of files show up in their merge attempt that have nothing to do with their fix. Not only the release artifacts, but also a critical fix Antoine applied to ssl.py a week after the 3.2.5 release. It turns out that one was already applied to later branches, but I know that only because Antoine said so here. Do the "null merge", and none of those questions will arise. And, indeed, that's _why_ we want to do null merges (when applicable) in general - right? So that future merges become much easier. BTW, it's not quite a null-merge. The v3.2.5 release tag doesn't currently exist in the 3.3 or default .hgtags files. So long as 3.2 has a topological head, people on the 3.3 and default branches won't notice (unless they look directly at .hgtags - they can still use "v3.2.5" in hg commands successfully), but that's mighty obscure ;-)

[Brett]

... After reading that sentence I realize there is a key "not" missing: "I see no reason NOT to help visibly shutter the 3.2. branch ...". IOW I say do the null merge. Sorry about that.

No problem! Since I've been inactive for a long time, it's good for me to practice vigorously defending what's currently documented - tests my understanding, and lets me annoy people at the same time ;-) Here's what I intend to do (unless an objection appears): hg up 3.3 hg merge 3.2 # merge in the v3.2.5 tag definition from .hgtags, # but revert everything else hg revert -a -X .hgtags -r . hg resolve -a -m hg diff # to ensure that only the v3.2.5 tag in .hgtags changed hg commit and then much the same steps to merge 3.3 into default. BTW, "null merging" this way is annoying, because at least in my installation kdiff3 pops up for every uselessly conflicting file. Anyone know a reason not to do: hg -y merge --tool=internal:fail 3.2 instead? I saw that idea on some Hg wiki.

On 8/21/2013 4:52 PM, R. David Murray wrote:

On Wed, 21 Aug 2013 14:34:33 -0500, Tim Peters wrote:

...

[Brett]

...

... After reading that sentence I realize there is a key "not" missing: "I see no reason NOT to help visibly shutter the 3.2. branch ...". IOW I say do the null merge. Sorry about that.

No problem! Since I've been inactive for a long time, it's good for me to practice vigorously defending what's currently documented - tests my understanding, and lets me annoy people at the same time ;-)

Here's what I intend to do (unless an objection appears):

hg up 3.3 hg merge 3.2 # merge in the v3.2.5 tag definition from .hgtags, # but revert everything else hg revert -a -X .hgtags -r . hg resolve -a -m hg diff # to ensure that only the v3.2.5 tag in .hgtags changed hg commit

You'll need a push here, too. And at that point it may fail. It may be the case that only Georg can push to 3.2, I don't remember for sure.

Where is the push to 3.2? I only see changes to 3.3 (to be repeated with 3.4).

I agree that it would cause less developer mind-overhead if the branch were merged.

-- Terry Jan Reedy

[Tim]

...

...

... Here's what I intend to do (unless an objection appears):

hg up 3.3 hg merge 3.2 # merge in the v3.2.5 tag definition from .hgtags, # but revert everything else hg revert -a -X .hgtags -r . hg resolve -a -m hg diff # to ensure that only the v3.2.5 tag in .hgtags changed hg commit

[R. David Murray]

...

You'll need a push here, too. And at that point it may fail. It may be the case that only Georg can push to 3.2, I don't remember for sure.

[Terry Reedy]

Where is the push to 3.2? I only see changes to 3.3 (to be repeated with 3.4).

Hi, Terry - long time no type :-) Merging 3.2 into 3.3 does make the original 3.2 head a parent of the merge changeset - I don't know whether whatever restrictions are in place would prevent that. I'd sure be _surprised_ if it prevented it, though ;-)

Am 21.08.2013 21:26, schrieb Brett Cannon:

On Wed, Aug 21, 2013 at 2:22 PM, Tim Peters mailto:tim.peters@gmail.com> wrote:

[Tim, wondering why the 3.2 branch isn't "inactive"] >> ... >> So let's try a different question ;-) Would anyone _object_ to >> completing the process described in the docs: merge 3.2 into 3.3, >> then merge 3.3 into default? I'd be happy to do that. I'd throw away >> all the merge changes except for adding the v3,2.5 tag to .hgtags. >> >> The only active branches remaining would be `default` and 2.7, which >> is what I expected when I started this ;-)

[Brett Cannon] > While I would think Georg can object if he wants, I see no reason to help > visibly shutter the 3.2 branch by doing null merges. It isn't like it makes > using hg harder or the history harder to read.

Well, why do we _ever_ do a null merge? Then why don't the reasons apply in this case?

After reading that sentence I realize there is a key "not" missing: "I see no reason NOT to help visibly shutter the 3.2. branch ...". IOW I say do the null merge. Sorry about that.

FWIW I have no real objections, I just don't see the gain. Georg

Am 24.08.2013 22:38, schrieb Tim Peters:

[Tim, wondering why the 3.2 branch isn't "inactive"]

[Georg Brandl]

...

FWIW I have no real objections, I just don't see the gain.

I'm glad it's OK! Especially because it's already been done ;-)

Two gains:

1. "hg branches" output now matches what the developer docs imply it should be. It didn't before.

Well, the dev docs are not dogma and could be changed :)

2. If a security fix needs to made to 3.2, it will be much easier to forward-merge it to the 3.3 and default branches now (the merges won't suck in a pile of ancient, and unwanted, irrelevant-to-the-fix changes).

It's unusual to develop a security fix on 3.2; usually the fix is done in the active branches and then backported to security-only branches. But I get the consistency argument (and especially the .hgtags entry is nice to have in the newer branches). cheers, Georg

[Tim]

...

BTW, it's not quite a null-merge. The v3.2.5 release tag doesn't currently exist in the 3.3 or default .hgtags files. So long as 3.2 has a topological head, people on the 3.3 and default branches won't notice (unless they look directly at .hgtags - they can still use "v3.2.5" in hg commands successfully), but that's mighty obscure ;-)

[Éric Araujo]

IIRC Mercurial looks at the union of .hgtags in all unmerged heads to produce the list of existing tags. :-)

Right! That's the obscure reason why v3.2.5 works even on branches where .hgtags doesn't contain a v3.2.5 entry - but will fail if 3.2 ceases to have "a topological head" (unless 3.2's .hgtags is merged to a still-active branch).