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
_______________________________________________
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
