qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rafael Schloming <rafa...@redhat.com>
Subject Re: M3 Freeze
Date Wed, 06 Aug 2008 01:41:54 GMT
Alan Conway wrote:
> On Tue, 2008-08-05 at 13:50 +0100, Aidan Skinner wrote:
>> On Tue, Aug 5, 2008 at 1:41 PM, Gordon Sim <gsim@redhat.com> wrote:
>>
>>> Can you remind me the process that was agreed around branching?
>> What I recall us settling us on was "don't, not unless there's a
>> (customer money) gun to your head and it can't possibly wait until the
>> next release".
> 
> What I recall us saying is "don't until you really need one". We need
> one if there is any post-M3 work going on during the freeze. I'm working
> on clustering code that is well decoupled but still poses a risk of me
> breaking the C++ broker. There may be others working on post-M3 work as
> well.
> 
> I'd suggest we create an M3 branch and allow post-M3 work on trunk,
> merging M3 to trunk as we go. The alternative is to use trunk for M3 and
> create a post-M3-branch but that seems backwards to me. 

I thought what we said was that in general during a project-wide 
release, most everyone should be focused stabilizing trunk, and that if 
someone really really needs to do new feature development during that 
period, they should create a feature branch.

Doing feature development during a release creates more work for 
everyone, so I tend to think a policy that discourages it, or at least 
puts the merge burden onto those doing the new feature development is 
quite sensible.

Ultimately the choice of how to branch comes down to who is doing the 
merging. If we branch for M3 prior to stabilizing, we either need a 
double commit policy (every commit needs to be both to the M3 branch and 
trunk) or we need to do a wholesale merge once the release is done. The 
latter option completely defeats your goal of integrating early and 
often, and the former option is a huge burden considering that it takes 
easily an hour to rigorously run through all the various java test 
profiles prior to committing to just one branch.

If you flip things around and take a feature branch then its essentially 
you (and probably me) doing merges from trunk whenever we feel the urge 
to integrate, and we will be in a much better position to resolve any 
merge conflicts since we'll be familiar with both the old code and the 
new code.

So as someone who's likely to be participating on both sides of this, I 
tend to think creating a feature branch is going to be much less work 
all around.

--Rafael

Mime
View raw message