Philipp von Weitershausen wrote:
> Tres Seaver wrote:
>> That is an enormous amount of effort: major kudos to him for being
>> willing to tackle it. I think that in some cases, such a practice will
>> not necessarily going to give the highest-quality result: the
>> "backporter" won't always have as much context about the bug as the
>> original "fixer", and may not be able to ensure that it is fixed
> Yes. We don't have a Hanno for Zope 3.
And even if there would be someone willing to do this job, a good
understanding of most of the internals would be a prerequisite, as
merging something which you do not understand is indeed potentially
extremely harmful. The number of people that have a deep understanding
of most internals of Zope3 is fairly limited and I think their time is
better spent on fixing the bugs in the first place.
>> I'm actually arguing against calling it "backporting" at all: the point
>> is that it is *more* urgent to fix the bug on a release branch than to
>> do so on the trunk, so we should refer to the process as
+1, as mentioned in my other post, in Plone we do not do any backporting
>> Pragmatically, it is typically *easier* to forward-port a bugfix than to
>> backport it, because the "common ancestry" in the merge is more likely
>> to be helpful.
>> Of course, some kinds "janitorial" practices (e.g., tidying up
>> whitespace, imports, etc.) can make this harder if done only on the
>> trunk. That sort of friction is one of the reasons why change velocity
>> drops off on successful projects.
> Well, the moving around stuff in Zope 3.3 (and the more moving that's
> expected in the future wrt more egg-friendliness) will make such merges
> harder, but not impossible.
This certainly makes it more time consuming but not really any harder ;)
Zope3-dev mailing list