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? _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
