This is the mail archive of the mauve-discuss@sourceware.cygnus.com mailing list for the Mauve project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Mauve compatibility intent


>>>>> "Dave" == Dave Roberts <dave@droberts.com> writes:

Dave> Does Mauve have any sort of "mission statement" in this regard?

There's the FAQ.

Dave> I know this sounds a bit pedantic, but I'm at a loss as to what
Dave> Mauve compatibility might mean if it doesn't. Further, there
Dave> must be some guidance to test authors. It's hard enough to get
Dave> people to write tests; you don't want people having to write two
Dave> sets of tests for every class, one for abstract API
Dave> compatibility and one for Sun JDK compatibility. They aren't
Dave> very likely to do it. Worse, without it specified as to what
Dave> test authors should try to test to, each author is likely to
Dave> test different things, leading to a total set of Mauve tests
Dave> that don't run cleanly on *any* implementation.

It seems chaotic but in practice I don't think it is that bad.

I see Mauve as a more inclusive test suite.  You can choose different
tags to let you test against different things.  So we can support
both, if we ant.

FWIW I think everybody has been testing against the API documentation
and not Sun's implementation.

For libgcj, we don't test against all of Mauve.  We don't implement
everything Mauve needs.  Instead we use tags to choose the subset that
makes sense for us.

So I think what we really need is to nail down even more precisely
what each tag means.  I agree this is something we've been bad at.
Mauve has really been languishing for a while -- there have only been
sporadic changes to it.  Bummer.

Dave> Now, while #2 seems more "pure" in the abstract sense, I think
Dave> #1 is actually more practical. In cases where a given company
Dave> controls both the API spec and the dominant implementation, #2
Dave> is largely futile in the long term.

I think both choices are bad for roughly the same reasons.  If we
agree that Sun's documentation will always suck, then we are saying
that the WORA promise of Java is impossible (how can I write Java code
that I know to be WORA unless I can read what the code is supposed to
do?).  But if we say the docs are canonical then we have the problems
you mention.

Tom

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]