Mailing-List: contact dev-help@stdcxx.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@stdcxx.apache.org
Received-SPF: pass (athena.apache.org: domain of msebor@gmail.com designates
 209.85.198.184 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=message-id:date:from:organization:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding:sender;
        b=tyrNHLDSMcYgPml3g3G5kKhie6lIEcgz4z5YymviLLwNUHE8XzNPsfCBbfuCiQ+4Lnxdl7ImvF3jd45N22OlCAnob0m/h6PDNP0gc0yPmitK8XyhRBsvB79hvis4uHJEmxuePDCSHQ5FE8CUl7kQTfsXiQgLXELRui4Ss5dwLW8=
Message-ID: <47F2B9FD.50202@roguewave.com>
Date: Tue, 01 Apr 2008 16:41:01 -0600
From: Martin Sebor <sebor@roguewave.com>
Organization: Rogue Wave Software, Inc.
User-Agent: Thunderbird 2.0.0.12 (X11/20080226)
MIME-Version: 1.0
To: dev@stdcxx.apache.org
Subject: on branches and merging (was: Re: failing regression tests)
References: <47ED5834.4030803@roguewave.com>
 <7BDB2168BEAEF14C98F1901FD2DE643801EA9050@epmsa009.minsk.epam.com>
 <47F29D22.5060801@roguewave.com>
 <CFFDD219128FD94FB4F92B99F52D0A499AA7E3@exchmail01.Blue.Roguewave.Com>
 <47F2AB7A.2070205@roguewave.com>
 <CFFDD219128FD94FB4F92B99F52D0A499AA7E4@exchmail01.Blue.Roguewave.Com>
In-Reply-To: 
 <CFFDD219128FD94FB4F92B99F52D0A499AA7E4@exchmail01.Blue.Roguewave.Com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: Martin Sebor <msebor@gmail.com>

Travis Vitek wrote:
>  
> 
>> Martin Sebor wrote:
>>
>> Travis Vitek wrote:
>>>  
>>>
>>>
>>> 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.
> 
> I don't mind it being unstable,

Stability is increasingly important as we approach a release.
Every major breakage (like the one we just had on trunk) sets
us back by days if not a week, sometimes up to 10 days when
the build servers are busy.

> provided that we are actually testing
> that branch. I don't think we are testing 4.2.x, so we don't even know
> if it is stable or not. When we get close to release time, we should
> probably be testing 4.2.x almost exclusively.

Scott tells me we have been testing 4.2.x in nightly builds for
some time. I just haven't gotten around to publishing the results
yet. I need to do it soon. I think I'll need Andrew's help to set
up the script(s).

> 
>> 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...
> 
> Are you saying that the test infrastrucure doesn't allow us to test
> 4.2.x at all? I can see how that would be a serious problem. How are we
> expected to verify that the code that is on 4.2.x is good?

What I'm saying is that it might be a hard sell to get Rogue Wave
to run two (or more) sets of nightly builds for stdcxx, one for
trunk and one for each branch, unless it's much more lightweight
than it is now.

> 
>> 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.
> 
> Well, for a while there Farid was working directly on 4.2.x and merging
> back to trunk. That solution would work. Another obvious option would be
> to require users to merge their own changes out. We were doing this for
> a hile, but I've noticed that this hasn't been happening lately.

It hasn't because we haven't been testing the branch (or
publishing the results). We could switch nightly builds to 4.2.x
but then we'll have the same problem on trunk and/or on any other
branch (such as 4.3 or 5.0, once they've been created). We already
have a number of patches and tests that we've been waiting to
commit because they're not appropriate for 4.2.x and we've been
treating trunk as a copy of 4.2.x. I think that's a mistake.
We should commit these patches otherwise they are at risk of
becoming out of sync with the files they patch. Then it'll be
a chore to apply them all.

I guess my point is that it doesn't matter if it's a branch or
trunk that gets tested, or where some/many of us do their work,
there's nothing we can do to get away from merging the changes
at some point. So it seems that we need to come up with
a solution to the merging problem, independently of what we
do about testing.

Martin