<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Aug 21, 2013 at 2:22 PM, Tim Peters <span dir="ltr"><<a href="mailto:tim.peters@gmail.com" target="_blank">tim.peters@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">[Tim, wondering why the 3.2 branch isn't "inactive"]<br>
>> ...<br>
</div><div class="im">>> So let's try a different question ;-)  Would anyone _object_ to<br>
>> completing the process described in the docs:  merge 3.2 into 3.3,<br>
>> then merge 3.3 into default?  I'd be happy to do that.  I'd throw away<br>
>> all the merge changes except for adding the v3,2.5 tag to .hgtags.<br>
>><br>
>> The only active branches remaining would be `default` and 2.7, which<br>
>> is what I expected when I started this ;-)<br>
<br>
</div>[Brett Cannon]<br>
<div class="im">> While I would think Georg can object if he wants, I see no reason to help<br>
> visibly shutter the 3.2 branch by doing null merges. It isn't like it makes<br>
> using hg harder or the history harder to read.<br>
<br>
</div>Well, why do we _ever_ do a null merge?  Then why don't the reasons<br>
apply in this case?<br></blockquote><div><br></div><div>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.</div>

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