-----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 [EMAIL PROTECTED] 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----- _______________________________________________ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com