jtreg testing integrated
Andrew John Hughes
gnu_andrew at member.fsf.org
Thu May 22 14:56:46 PDT 2008
On 22/05/2008, Mark Wielaard <mark at klomp.org> wrote:
> Hi Andrew,
> On Thu, 2008-05-22 at 01:23 +0100, Andrew John Hughes wrote:
> > Indeed, I believe Mark started looking into this specifically for this
> > reason; so that the tests could be run on the OpenJDK being packaged
> > in distributions and so the community could have a goal to work
> > towards in fixing any issues.
> The reason I wanted the testsuite integrated into the normal build and
> hopefully run on as many platforms/setups as possible was to spread the
> testing effort as wide as possible. And to hopefully come to a common
> baseline that all derivatives would follow as minimum quality that
> should be reached. We will never be able to centrally test every
> configuration/hardware/os setup, so it is important that the end user
> can eventually do it themselves.
Seems very sensible to me.
> > So I apologise if any of my comments read as being abrasive or as not
> > understanding the issues of Sun's 'production build'. But it's
> > something very foreign to us, and something I'd expect to remain so,
> > while the production build remains a proprietary product.
> Actually I don't think it is that foreign. We have always had derivative
> works that are slightly different because of platform/runtime setups. It
> is good we have some common test suites that can be run on all of them.
> What is somewhat foreign is singling out one derivative as "the
> production build" which has a configuration which is actually different
> from the upstream defaults. We shouldn't hard code such configurations
> into the testsuite, but it is certainly desirable to make them possible.
Yes, I wasn't saying that the general concept was foreign. The point
was more that we aren't aware of the various oddities of Sun's
production build. Deliberately obscuring classes as Joe mentioned is
certainly a very foreign and worrying idea to me.
The 'singling-out' proposition is not so much foreign, as something
we'd simply try not do because it's an inherently bad and biased idea.
I believe the closest we've come is in not adding code because we
knew it would break particular VMs or compilers. For example, I
recall issues with the original gcj compiler and the accessibility
classes. But this would be the equivalent of adding a test to Mauve
that tested explicitly for Kaffe for example, which I don't believe
we've ever done or would want to do.
Support Free Java!
Contribute to GNU Classpath and the OpenJDK
PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
More information about the distro-pkg-dev