Tres Seaver wrote:
Stephan Richter wrote:
On Friday 08 September 2006 04:12, yuppie wrote:
Are there good reasons why these changes were not backported?

I volunteer to backport some fixes I'm missing in Zope 3.2, but that's
no general solution for keeping the current stable branch maintained.
The short answer is: We are a bit sloppy. I always develop against the trunk, so when I fix an issue, I do not event think about porting it back to another release, other when one is imminent, like Zope 3.3 now. I think most other Zope 3 developers are the same.

I consider this practice unacceptable for work on an allegedly
ready-for-production package.  The Zope Development Process document [1]

  When you check in a bug fix, you almost always need to:

    * Check in the fix on the current release branch
    * Note the fix in the /doc/CHANGES.txt on the current release branch
    * Merge the fix to the trunk to be sure its fixed for the next
      feature release

Only "feature work" should be done primarily on the trunk.

I agree. In Five, for example, I would first fix the bug in the oldest maintenance release, e.g. Five 1.2, and then merge it onwards to all newer branches (1.3, 1.4, trunk). I realize this involves a lot of merging, but all of these branches are in maintenance mode, so they do need to be adressed. I wrote a little tool that made simple bugfix merges like that really easy [1]. The only time spent is running tests (during which I usually do my emails).

I think the problem with Zope 3 is two-fold:

* We don't have an actual policy of what is still a maintenance release. In Zope 2, we say that we'll maintain a release for 1 year. So that means you'll always have two stable branches (e.g. 2.8 and 2.9) and one development branch (2.10) which may or may not be the trunk at the time, depending on whether we're before or after feature freeze.

* Many Zope 3 developers are on the bleeding edge. And with bleeding edge I mean trunk. Bugfixes sometimes only get *back*ported from the trunk to the latest release branch. It should be the other way around.

As Zope 3 is part of Zope 2 now, I think we should be maintaining old release branches as long as their correspondent Zope 2 release branch is maintained. That means we should change policy so that Zope 3 releases are maintained for 1 year as well, and that bugfixes will first go into Zope 3.2, then into 3.3 and then the trunk. With most of the bugfixes and the right tools (e.g. ezmerge), this isn't as much work as it sounds.


Zope3-dev mailing list

Reply via email to