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

[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.

>     And from a distributor/vendor point of view, I
>     think yearly releases are too seldom. Such a release could end up
>     only up to 24 months later in a (linux) distribution.

Some subset of 'we' proposed 5 instead of 2 years of bugfix support for 
2.7, released 2010 July 4, but no particular interval, especially after 
the first 2 years.

>   - 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?

 >  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 ;=).

 >  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.

-- 
Terry Jan Reedy