[Zope3-dev] Re: Zope 3.2 maintenance

[Philipp von Weitershausen]

Tres Seaver wrote:
> Rocky Burt wrote:
>> On Mon, 2006-11-09 at 11:28 -0400, Tres Seaver wrote:
>>> Philipp von Weitershausen wrote:
>>>> Jim Fulton wrote:
>>>>> I agree in principle.  In practice, I'm not sure we have enough
>>>>> maintainers to get a release out, let alone maintain two previous
>>>>> release branches. :(   We need more volunteers.
>>> The marginal effort to do the bugfix correctly (i.e., first on the
>>> release branch, then forward-porting to any beta branch and the trunk)
>>> is not that big.  If we can't get our volunteers to do that, then maybe
>>> we need to quit pretending that Zope3 is or ever will be "production
>>> ready."  Without such a practice (which Zope2 has had since before
>>> community checkins), how can we expect anybody to take Zope3 seriously?
>> I've only ever worked on one open source project where I was not
>> supposed to backport my fixes to the maintenance release branches and
>> that is Plone.  For Plone we have someone responsible for back-portting
>> that stuff in bulk.  It makes his job harder if we manually back-port
>> fixes as then he has to be more selective with the patches he backports.
>>
>> Thanks Hanno!
> 
> 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.

>> But my point is it is pretty standard behaviour to have to backport
>> fixes to all actively maintained branches.
> 
> 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

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

Philipp