[Zope3-dev] Re: Zope 3.2 maintenance

[Philipp von Weitershausen]

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]
> states:
> 
>   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.

Philipp


[1] 
http://www.z3lab.org/sections/blogs/philipp-weitershausen/2006_08_23_how-python-solves-my