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: local policy)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: failing regression tests
Date: Tue, 1 Apr 2008 16:08:06 -0600
Message-ID: 
 <CFFDD219128FD94FB4F92B99F52D0A499AA7E4@exchmail01.Blue.Roguewave.Com>
Thread-Topic: failing regression tests
Thread-Index: AciUQPrWJHZVnWwXSGG6o4j7ZReU2AAAm4kQ
References: <47ED5834.4030803@roguewave.com>
 <7BDB2168BEAEF14C98F1901FD2DE643801EA9050@epmsa009.minsk.epam.com>
 <47F29D22.5060801@roguewave.com>
 <CFFDD219128FD94FB4F92B99F52D0A499AA7E3@exchmail01.Blue.Roguewave.Com>
 <47F2AB7A.2070205@roguewave.com>
From: "Travis Vitek" <Travis.Vitek@roguewave.com>
To: <dev@stdcxx.apache.org>

=20

>Martin Sebor wrote:
>
>Travis Vitek wrote:
>> =20
>>=20
>>=20
>> I'm thinking that all work for 4.2.1 should be done on the=20
>> 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.
>>=20
>> Unfortunately, I think that would mean that we would need to=20
>> 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, 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.

>
>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?

>
>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.

>
>Martin
>