[Zope3-dev] Re: Release management refinements

[Philipp von Weitershausen]

Florent Xicluna wrote:
> 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,

"all" refers to one more. There are at most only two 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.

If you can merge and run tests once, you can merge and run tests twice. 
It's mostly mechanical. Heck, I can do it on my sloooow PowerBook. Most 
of you guys have fast Intel machines :).

> And if i have not enough knowledge of old release 3.X, this is a pain to do the
> merge.

That's why it's best to fix the bug on the oldest still maintained release.

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

Who's that someone? Are you volunteering to do it?

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

That requiers we that "person in charge for release 3.X". We currently 
don't have that someone.