stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <>
Subject Re: failing regression tests
Date Tue, 01 Apr 2008 21:39:06 GMT
Travis Vitek wrote:
>> Martin Sebor wrote:
>> Farid Zaripov wrote:
>>>> Martin Sebor wrote:
>>>> The regression tests below are all failing with SIGABRT.
>>>> I check the issues and they have all been deferred, so what's 
>>>> missing is an entry for each of these tests in xfail.txt to 
>>>> mark them up on our build result pages.
>>>>      21.string.assign.stdcxx-629
>>>>      21.string.insert.stdcxx-630
>>>>      21.string.insert.stdcxx-632
>>>>      21.string.replace.stdcxx-170
>>>> Farid, I think these are all your issues. Can you please take 
>>>> care of updating xfail.txt when you have a chance?
>>>   Done. It seems that the 21.string.insert.stdcxx-630 test 
>>> is added by my mistake (the STDCXX-630 issue is about assign
>>> string method and not about insert). So I deleted this test
>>> from trunk.
>> 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...

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.


View raw message