[Zope3-dev] Re: Release management refinements

[Philipp von Weitershausen]

Stephan Richter wrote:
> On Wednesday 13 September 2006 11:02, Florent Xicluna wrote:
>> Currently, I work with 3.3 branch for my company. I checked out the trunk
>> too, in order to collaborate to Zope development.
>> So I have both '/trunk' and '/branches/3.3/' on my computer. When I prepare
>> a fix I do it on the 3.3 branch, I make unit/functional tests. Then I do
>> manual tests on my sandbox, and I commit to the branch.
>> Later I merge to the trunk, do unit/functional tests again and commit to
>> the trunk.
>> This is acceptable workload for me.
> 
> I work this way too.

Contributing to a community also means adapting to its processes and way 
of working. The process has been working well for Zope 2 developers, so 
I don't see why it can't work for Zope 3.

> We develop against the trunk.

That shouldn't be an obstacle (see below).

> And I always make a writable checkout. When I fix a bug, I will 
> always do this on the trunk first, because I need to make sure that 
> my customer code really works after the fix. It is not sensible for
> me to fix other branches first.

This process isn't only about what's sensible to you or your customer. 
It's also about those people who use stable releases and would like them 
to be maintained. Heck, Zope 3.3 isn't even final yet (so Zope 3.2 is 
still stable!) and nobody is fixing things in Zope 3.2. That's simply 
unacceptable.

Plus, "I need to make sure that my customer code really works after the 
fix" makes it sound like we have no tests. The usual drill is to produce 
a minimal test failure (and that usually means outside customer code) 
and then fix the bug until the test passes.

So, even if you develop against the trunk and notice a bug there, you 
can switch to the oldest maintained branch, whip up a test case there 
(which is needed anyways because we'd need to know whether the problem 
applies to that branch as well) and fix the bug. THen you can merge 
onward till the fix is on the trunk.

> I could live with the policy of also supporting two release branches, but I 
> would prefer only having to worry about one.

Sure, we'd all prefer that, wouldn't we. ;)

> BTW, a pain-easing script for merging would come a long way, in my
> opinion.

Generally I like svk's and svnmerge's approach with sticking properties 
with merging information on the files and dirs that have been worked on. 
But their approach requires that this practice is generally adopted. I 
wrote a braindead simple merging tool called ezmerge that serves me well 
90% of the time:

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