[Zope3-dev] Re: Release management refinements

[Florent Xicluna]

Philipp von Weitershausen <philipp <at> weitershausen.de> writes:

> Over the last couple of days we've been discussing Zope's new release 
> cycle and the release management. I would like to sum up what seems to 
> be the gist of those discussions:

I agree with the overall policy to improve the release machinery.

> 
> 1. Fix the bug in the *oldest* maintained branch (e.g. Zope 2.8 still)
> 
> 2. Merge the bugfix to newer release branches (e.g. Zope 2.9 and 2.10)
> 
> 3. Merge the bugfix to the trunk
> 
> [snip]
> 
> Thoughts?
> 

However i have a worry on the "Fix oldest branch, merge to newer branches".
I guess this is due to my young experience with SVN development.

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.

But if I need to checkout/update all previous maintenance releases, and if i
need to perform merge+tests+commit three times for every single bug, this seems
a big work load to fix a bug.
And if i have not enough knowledge of old release 3.X, this is a pain to do the
merge.

IMHO, i would prefer to keep the current bugfix policy (i.e. commit to working
release+trunk) and to have for each release someone that will do merging.
In order to facilitate this process, we can enforce a workflow where committer
will warn the person in charge for release 3.X, to ask him to merge rev. 700xx
to release 3.X.
For heavy changes, or if the person in charge has not enough information to
perform the merge, he can ask the committer for help, or ask the committer to do
the merge himself.

This is my 2 cents about this.
If I am the only lazy guy here, go on with the proposed bugfix policy.
Of course, I will adapt myself ;-)


-- Florent