RE: svn commit: r693419 - /stdcxx/branches/4.3.x/etc/config/xfail.txt

[Travis Vitek-4]

>-----Original Message-----
>From: faridz@... [mailto:faridz@...]
>
>Author: faridz
>Date: Tue Sep  9 03:20:19 2008
>New Revision: 693419
>
>URL: http://svn.apache.org/viewvc?rev=693419&view=rev
>Log:
>2008-09-09  Farid Zaripov  <faridz@...>
>
> Merged r693416 from branches/4.2.x
>
> * etc/config/xfail.txt (21.string.exceptions): Added an expected
> test failure due to STDCXX-1009.
> (21.string.stdcxx-1009): Added an expected test failure due to
> STDCXX-1009.
> (25.uninitialized.copy.stdcxx-976): Added an expected
> test failure due to STDCXX-976.
>

Is there some reason that you didn't just fix the regression shown in
STDCXX-1009?

Travis

>Modified:
>    stdcxx/branches/4.3.x/etc/config/xfail.txt
>
>Modified: stdcxx/branches/4.3.x/etc/config/xfail.txt

[Farid Zaripov-3]

> Is there some reason that you didn't just fix the regression shown in
> STDCXX-1009?

  Firstly, I found the regression some time later that I commited changes in
xfail.txt.

  Secondly, I want fix the regression and at the same time leave STDCXX-968
fixed :)

  Can you, please, verify that replacing 1 with 1L don't issues any warnings
on 32-bit and 64-bit aCC?

Farid.

[Farid Zaripov-2]

> Is there some reason that you didn't just fix the regression shown in
> STDCXX-1009?

  Firstly, I found the regression some time later that I commited changes in xfail.txt.

  Secondly, I want fix the regression and at the same time leave STDCXX-968 fixed :)

  Can you, please, verify that replacing 1 with 1L don't issues any warnings on 32-bit and 64-bit aCC?

Farid.

[Martin Sebor-2]

Farid Zaripov wrote:
>> Is there some reason that you didn't just fix the regression shown in
>> STDCXX-1009?
>
>   Firstly, I found the regression some time later that I commited changes in xfail.txt.

Perhaps we need to define the process for when a failure should
go in xfail.txt? I'd be inclined to mark a failure expected on
a given branch when it can't be fixed on that branch given the
release criteria (e.g., because it's incompatible). Would that
work for everyone?

Martin

>
>   Secondly, I want fix the regression and at the same time leave STDCXX-968 fixed :)
>
>   Can you, please, verify that replacing 1 with 1L don't issues any warnings on 32-bit and 64-bit aCC?
>
> Farid.
>

[Farid Zaripov-2]

> Perhaps we need to define the process for when a failure should
> go in xfail.txt? I'd be inclined to mark a failure expected on
> a given branch when it can't be fixed on that branch given the
> release criteria (e.g., because it's incompatible). Would that
> work for everyone?

  As I understand the expected failure is failure, for which we have
unresolved JIRA issue and no matter in which release this issue is
planned to fix. When someone fix the issue he should remove
corresponding entry in xfail.txt. In ideal case the all failures at the
test results page should be an expected. Of course if some failure
can be fixed in one day (before the next nightly test results will be
obtained) there no needs to mark this failure as expected. IMHO.

Farid.

[Martin Sebor-2]

Farid Zaripov wrote:

>> Perhaps we need to define the process for when a failure should
>> go in xfail.txt? I'd be inclined to mark a failure expected on
>> a given branch when it can't be fixed on that branch given the
>> release criteria (e.g., because it's incompatible). Would that
>> work for everyone?
>
>   As I understand the expected failure is failure, for which we have
> unresolved JIRA issue and no matter in which release this issue is
> planned to fix. When someone fix the issue he should remove
> corresponding entry in xfail.txt. In ideal case the all failures at the
> test results page should be an expected. Of course if some failure
> can be fixed in one day (before the next nightly test results will be
> obtained) there no needs to mark this failure as expected. IMHO.

So this definition doesn't doesn't distinguish between test failures
that can't be fixed due to compatibility restrictions from those that
can be fixed in a compatible way but that we haven't had time to fix
yet.

It occurs to me that tests that exercise bugs that can't be fixed in
a compatible way would be better dealt with by disabling them in code
using a suitable #if conditional. I.e., we don't need xfails for those.
The only purpose of xfails is then to mark up test failures that we
haven't gotten around to, like you said :)

Unless someone has a different opinion I'll update STDCXX-683 with
a link to Farid's definition in this discussion.

Martin