qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Vinoski <vino...@iona.com>
Subject Re: Proposed steps to migrate to AMQP 0-9
Date Tue, 02 Jan 2007 20:50:36 GMT

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.


View raw message