[python-committers] [PSF-Members] Code Simplicity » Open Source Community, Simplified

Terry Reedy tjreedy at udel.edu
Fri Feb 4 20:55:06 CET 2011



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


More information about the python-committers mailing list