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.
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".
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.
Zope3-dev mailing list