On Wed, Aug 21, 2013 at 2:22 PM, Tim Peters <tim.pet...@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. > > 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 ;-) > Yes it is. =)
_______________________________________________ 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