[Zope3-dev] Re: Zope 3.2 maintenance
Jim Fulton
jim at zope.com
Mon Sep 11 10:02:22 EDT 2006
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
More information about the Zope3-dev
mailing list