On 2/4/2011 1:41 PM, Jesus Cea wrote:
Remember the rule: "Patches in n+1 are a SUPERSET of patches in n".
This is simply not true of 2.7 versus 3.2. 3.x is a fork off of 2.x at
about 2.6. There are many 2.7-only bugs whose patches should not be
forward ported, either 'by hand' or by auto merge.
a patch in "n+1" can undo a patch in "n", keeping this rule true always.
The usual approach is to do a merge just before the patch you don't
want, and then a "null merge" just after the patch you don't want. "null
merge" = a merge metadata update without actually bringing any new code.
Seems like a lot of work to satisfy an artificial rule.
At one time, things were simple. There was an active maintenance branch
and trunk. When trunk was released as 2.k final and a new, 2nd
maintenance branch created, the older maintenance branch was released as
2.(k-1).m rc1 and (hopefully) a week later, 2.(k-1).m final and retired,
thus restoring the number of maintenance branches to one. Whether bug
patches went forwards or backwards between maintenance and trunk did not
matter too much.
It was later decided to put maintenance branches into security-fix mode
for a few years before freezing them, but in practice, this has meant
little difference.
The problem now is that we have a second, increasingly divergent
maintenance branch, and will for several years. Python is literally a
two-headed giant (monster?-). So I do not think forcing it into a
single-head model will work very well. (Note that from a temporal
viewpoint, 2.7 -> 3.1 -> 3.2 is backwards, then forwards.)
As a user of 3.x (and not 2.x), I will work on bug fixes for 3.x. If the
bug involves 2.7 also and the fix transports easily to 2.7, fine. If
not, someone who cares about 2.7 can do the additional work.
---
Terry Jan Reedy
_______________________________________________
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers
