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
>> properly.
> 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
>> "forward-porting".
> +1

+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
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to