[Python-Dev] cpython (2.7): - Issue #17086: Backport the patches from the 3.3 branch to cross-build (original) (raw)

Matthias Klose doko at ubuntu.com
Wed Feb 6 14:16:13 CET 2013

Am 05.02.2013 07:13, schrieb Terry Reedy:

On 2/4/2013 3:04 PM, Matthias Klose wrote:

- the 2.7 branch is the only branch which doesn't have expected release dates on the calendar. Which calendar? I see 2.7.4, 3.2.4 (its final release), and 3.3.1 on the Release Schecule at python.org.

maybe these are now updated. until recently 3.3.1 was targeted for Nov/Dec 2012, and 2.7.4 wasn't found on the calendar.

- there were way too may regressions checked in on at least the 2.7 branch. Regressions? That normally means adding a bug as part of a patch, especially one that was previously fixed. We continually add tests to try to prevent that. What period of time do you mean 'were' to refer to?

not a complete list, all these are past the 2.7.3 release.

Is it just our vcs merge model that we first have to check in on the branches, and then merge to the trunk? Mercurial works best if merges are done in the forward direction. However, this is not relevant to 2.7 patches as they are pushed to tip but not merged. The repository is a two-headed monster ;=).

so it should be possible to delay patches for 2.7 until they don't show issues in 3.2 or 3.3.

Afaics python is the only project to have such an approach. Others have trunk first, maybe with immediate backport, maybe with later backport. If a patch is first commited to tip (for 3.4) and then backported to 3.3, then when the backport is pushed, a null merge is needed to avoid making a third head, and the dag looks messier. (I believe 'null merge' is the right term, but I have never done this.) My impression is that most 3.x bugfix patches merge forward with little or no change.

so is it only this technical limitation, why the bugfix process is defined this way?

More information about the Python-Dev mailing list