[Zope3-dev] Re: Zope 3.2 maintenance

[Tres Seaver]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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.

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

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.


Tres.
- --
===================================================================
Tres Seaver          +1 202-558-7113          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFBYYJ+gerLs4ltQ4RAl/fAJ474wC5H+0i15e/YPgmDqXb5h4GzQCgw9x0
IZ44jkt1FOtuHMV+3v6AUF4=
=+SWn
-----END PGP SIGNATURE-----