on branches and merging (was: Re: failing regression tests)

[Martin Sebor <se...@roguewave.com>]

Martin Sebor wrote:
> Travis Vitek wrote:
>>  
>>
>>> Martin Sebor wrote:
[...]
>>> I think we need to decide if trunk is supposed to be a copy of
>>> 4.2.x or if it's for development of future versions. If the
>>> latter, there's no problem with keeping tests like it there
>>> as long as they're passing or as long as there's an entry in
>>> xfail.txt. We just need to remember not to merge them (and
>>> fixes for them, if they're incompatible) out to 4.2.x.
>>>
>>> So, which is it? Do we keep trunk as a development version of
>>> 4.2.x or do we make changes on it that are incompatible with
>>> 4.2.x?
>>>
>>
>> I'm thinking that all work for 4.2.1 should be done on the 4.2.x branch,
>> and future work should be done on trunk until an appropriate branch has
>> been created. That way we avoid having to be careful about bulk merges
>> from trunk to 4.2.1... Everything that is on 4.2.x should be safe for
>> trunk.
>>
>> Unfortunately, I think that would mean that we would need to do nightly
>> testing on the 4.2.x branch, possibly in addition to trunk.
> 
> Right, that's a big problem. Another problem with this approach
> is that it has the potential to destabilize the branch.
> 
> The second problem can be mitigated by tagging the branch when
> it's known to be stable. I don't think there's anything we can
> do about the first problem except alleviate it by implementing
> a more intelligent test harness. I'm not sure we have cycles
> for that...

It occurs to me that even if most work were done on the release
branch(es) the changes would still need to merged only in the
opposite direction: from each branch to trunk and/or to other
branches. I'm afraid I don't see how the merging problem can
be avoided. Do you?

> 
> Is there some convention or process we could put in place that
> would make the bulk merge issue less painful? I wake up in the
> middle of the night thinking about how we're going to manage
> it for 4.2.1. Maybe it won't be so bad, but it does seem like
> it will be a lot work and could be pretty error prone.
> 
> Martin
> 

Re: on branches and merging

[Martin Sebor <se...@roguewave.com>]

Travis Vitek wrote:
>  
> 
> 
>> Martin Sebor wrote:
>>
>> It occurs to me that even if most work were done on the release
>> branch(es) the changes would still need to merged only in the
>> opposite direction: from each branch to trunk and/or to other
>> branches. I'm afraid I don't see how the merging problem can
>> be avoided. Do you?
>>
> 
> I don't see the merge itself as the most serious problem. The trouble is
> trying to figure out what changes can be merged out to 4.2.x from trunk.
> 
> I believe that we currently have some changes that aren't suitable for
> 4.2.x on trunk. When someone goes and tries to do the merge out, they
> have to make sure they do the merge correctly and they have to be
> careful to not merge changes that are incompatible with the target
> branches compatibility requirements. That is what I'm worried about.

Same here.

> 
> If the merging was going from 4.2.x to trunk, then the compatibility
> issue is moot.

Good point. The only problem here, and it's probably the one that
led to the current convention of making changes on trunk first,
before merging them to 4.2.x, is that we've had a good share of
changes that we thought were appropriate for 4.2.x that turned
out not to be.

The release process document tries to deal with this problem by
allowing changes on a release branch at first, until the RM has
decided it's time to start stabilizing the branch (Feature Freeze).
At that point the branch becomes RTC for everyone but the RM. In
practice what I expect this to mean is that development (including
bug fixing) will proceed on trunk (or other branches) with the RM
being responsible for doing the merges.

Since we haven't reached a "Feature Freeze" yet we should be able
to follow the process. The only two obstacles are: no test results
for 4.2.x, and our propensity to make incompatible changes. As I
said I'll take care of the first. I'm not sure how to handle the
second except by freezing the branch. Which will bring us a full
circle...

Martin

RE: on branches and merging (was: Re: failing regression tests)

[Travis Vitek <Tr...@roguewave.com>]

 


>Martin Sebor wrote:
>
>It occurs to me that even if most work were done on the release
>branch(es) the changes would still need to merged only in the
>opposite direction: from each branch to trunk and/or to other
>branches. I'm afraid I don't see how the merging problem can
>be avoided. Do you?
>

I don't see the merge itself as the most serious problem. The trouble is
trying to figure out what changes can be merged out to 4.2.x from trunk.

I believe that we currently have some changes that aren't suitable for
4.2.x on trunk. When someone goes and tries to do the merge out, they
have to make sure they do the merge correctly and they have to be
careful to not merge changes that are incompatible with the target
branches compatibility requirements. That is what I'm worried about.

If the merging was going from 4.2.x to trunk, then the compatibility
issue is moot.

Travis

Re: on branches and merging

[Martin Sebor <se...@roguewave.com>]

Eric Lemings wrote:
>  
> 
>> -----Original Message-----
>> From: Martin Sebor [mailto:msebor@gmail.com] On Behalf Of Martin Sebor
>> Sent: Tuesday, April 01, 2008 4:11 PM
>> To: dev@stdcxx.apache.org
>> Subject: on branches and merging (was: Re: failing regression tests)
>>
> ...
>> It occurs to me that even if most work were done on the release
>> branch(es) the changes would still need to merged only in the
>> opposite direction: from each branch to trunk and/or to other
>> branches. I'm afraid I don't see how the merging problem can
>> be avoided. Do you?
> 
> Sure.  Don't branch until all issues scheduled for the release have
> been resolved and you're ready to start testing release candidates.
> That way, all main development occurs in only one place only: on
> the trunk.

That doesn't work when there are several parallel development
efforts going on. In our case, they are: 4.2.x, 4.3, and 5.0.
As I just mentioned in my response to Travis we have changes
(or patches) for all three. We just haven't been committing
(or have been reverting) patches for the latter two because
they're not appropriate for 4.2.x. That's not workable.

There's no avoiding having development happen on multiple
branches at the same time. We need to figure out how to
make the process of merging changes between these branches
as easy as possible with the least chance of errors.

Martin

RE: on branches and merging (was: Re: failing regression tests)

[Eric Lemings <Er...@roguewave.com>]

 

> -----Original Message-----
> From: Martin Sebor [mailto:msebor@gmail.com] On Behalf Of Martin Sebor
> Sent: Tuesday, April 01, 2008 4:11 PM
> To: dev@stdcxx.apache.org
> Subject: on branches and merging (was: Re: failing regression tests)
> 
...
> 
> It occurs to me that even if most work were done on the release
> branch(es) the changes would still need to merged only in the
> opposite direction: from each branch to trunk and/or to other
> branches. I'm afraid I don't see how the merging problem can
> be avoided. Do you?

Sure.  Don't branch until all issues scheduled for the release have
been resolved and you're ready to start testing release candidates.
That way, all main development occurs in only one place only: on
the trunk.

Brad.