Home Original page

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

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?

 - http://bugs.python.org/issue9374
 - http://bugs.python.org/issue15906
 - http://bugs.python.org/issue16012
 - http://bugs.python.org/issue10182
 - http://bugs.python.org/issue16828

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