On Jan 2, 2007, at 3:10 PM, Kim van der Riet wrote:
On Tue, 2007-01-02 at 14:53 -0500, Steve Vinoski wrote:
4. It is understood that the implementation of the new message class
will take a week or two to complete, and that the trunk will be
non-functional until these changes are complete. At a minimum,
checkins
should compile, but may not pass all functional tests.
Rather than breaking trunk, why not do the work on a branch, and
merge it when it works?
5. A coordinated and simultaneous effort will be required to
update
the
C++, Java and Python codebase to implement and use the new frame and
message classes. The other clients can follow later.
Taking a branch would allow everything to be coordinated on the
branch and simultaneously merged when ready.
--steve
Overall, I don't think it matters much whether the effort occurs on a
trunk or on a branch... Certainly placing such a change on a branch is
more traditional. I would only add that making the change on the trunk
makes the effort more visible, and has the effect of focusing the
effort
required to make the change. Branches tend to be "invisible" to many
developers, and can be ignored until the merge. Part of the plan
here is
to make the change as visible as possible, and to involve as many as
possible in the updates.
But breaking trunk presumes there's no other work using it, which
isn't the case. For example, Robert has been moving some performance-
related tests around to be able to test the effects of all the recent
JMS-related changes, and Tej is still finishing up his queue browsing
work. I've been doing work related to the distribution, to fix issues
that would prevent M2. Martin or Marnie might be doing some other
work on the trunk as well.
Deliberately breaking trunk, even if it's a ploy to force people to
get involved to fix it, just seems like a bad idea IMO. You can have
the work on a branch and still have multiple people working on it,
and that way you don't break the work of others.
--steve
