Re: Analysis of Mauve failures - Part 2

[Mark Wielaard <mark at klomp dot org>]

Hi,

On Mon, 2002-04-08 at 22:45, Tom Tromey wrote:
> At one point most of the Mauve tests here worked for us.  Some
> regressions were introduced at some point, but I never got around to
> looking at them.  The Classpath calendar/time code is extremely
> sensitive to change.  In my experience it is hard to fix a bug without
> introducing a regression.

I would really like to go back to a state were we don't have any
unexpected failures for mauve (and Gnats reports for everything that we
expect to fail).

Would it it be OK for me to mark the remaining java.text mauve failures
as xfail and make bug reports for them? Or do you think you will
analyze/fix them before 3.1?

The failures that I am thinking of now would be:

FAIL: gnu.testlet.java.text.AttributedString.Test: Attribute key count
(number 1)
FAIL: gnu.testlet.java.text.DateFormatSymbols.Test: invalid locale
(number 1)
FAIL: gnu.testlet.java.text.SimpleDateFormat.regress: CDT (number 1)
FAIL: gnu.testlet.java.text.SimpleDateFormat.regress: EDT (number 1)
FAIL: gnu.testlet.java.text.SimpleDateFormat.regress: EST (number 1)
FAIL: gnu.testlet.java.text.SimpleDateFormat.regress: PDT (number 1)

But if you see others that you immediately know won't be further
analyzed/fixed for 3.1 please let me know.

Note my latest mauve results for i686-pc-linux-gnu can be found at
http://gcc.gnu.org/ml/gcc-testresults/2002-04/msg00259.html
(Only 42 unexpected failures to go)

There are also results for powerpc-unknown-linux-gnu, but they don't
look that good (110 unexpected failures).
http://gcc.gnu.org/ml/gcc-testresults/2002-04/msg00275.html

Cheers,

Mark