Dan Creswell wrote:
I think there are some other things we might consider:
(1) Do the tests in question always fail and only on SPARC?
Yes and only on the Java 6 JVM. The way security policy's are loaded
changed in Java 6. In reality a SecurityManager must be loaded at
startup with a policy provider, this is not our current practise, so we
do have some code which is not quite as good as it should be, but these
things take time to improve and we don't even know what the cause of the
bug is either. We could document the bug in the release, it's a
security issue with java 6 on sparc, at this point in time, it's
probably worth one last look at the bug before release.
Long term support for sparc is another issue, perhaps Oracle might be
kind enough to donate some sparc hardware to Apache.
(2) Do the tests in question contain any SPARC specific code?
No.
(3) Does the code being tested contain any SPARC specific code?
No.
(4) How many cores are available on the SPARC's in question vs other
machines we test on?
4 single core cpu's (slow 450Mhz), 1MB cache each, 4GB Ram, interleaved
memory.
Answering the above helps us understand whether we have a general issue or a
SPARC-specific issue. If it's SPARC-specific and none of our code is
SPARC-specific that points at environmental problems (OS patches, JVM
version etc). Would we hold up a release then? Would such a problem be a
River bug let alone a new River bug?
On 1 April 2011 11:05, Patricia Shanahan <[email protected]> wrote:
What is the definition of "new"? Remember we added a lot of QA tests that
were not being run previously, so for most QA tests we do not know whether
they would have passed on an earlier release.
If we can define "new" as being since some specific subversion check-out,
we can build that on a SPARC and see whether the failing test passes on it
or not.
Patricia
On 4/1/2011 2:40 AM, Tom Hobbs wrote:
I think themost important question is "have we introduced a new bug?". If
the answer is yes, then it becomes more difficult to justify a release.
But
depending on the likely impact of that bug (we could ask on users@) a
release might still be justifiable.
If the answer is no, I see no obvious reason to delay a release for it.
Especially given that the impact seems limited.
