[Zope3-dev] Re: Zope 3.2 maintenance

[Jim Fulton]

On Sep 10, 2006, at 9:38 AM, Philipp von Weitershausen wrote:

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

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.

If we want to maintain releases for a year, I suspect we need to  
release once a year.

Jim

--
Jim Fulton			mailto:jim at zope.com		Python Powered!
CTO 				(540) 361-1714			http://www.python.org
Zope Corporation	http://www.zope.com		http://www.zope.org