You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Stepan Mishura <st...@gmail.com> on 2007/09/22 18:18:04 UTC
[general] M3 - code frozen
Hi,
According to the plan - Sept. 22 is code freeze date for M3 so let's
follow policy:
"no more commits please without agreement from two committers on the dev list."
Let's do more testing and analyze if there any critical/blocker issues
for consideration.
Please raise here issues that you think MUST be fixed for M3.
Thanks,
Stepan Mishura
Intel Enterprise Solutions Software Division
Re: [general] M3 - code frozen
Posted by Mark Hindess <ma...@googlemail.com>.
On 25 September 2007 at 13:51, "Alexey Petrenko" <al...@gmail.com> wrote:
> 2007/9/25, Tim Ellison <t....@gmail.com>:
> > Alexey Petrenko wrote:
> > > 2007/9/25, Tim Ellison <t....@gmail.com>:
> > >> I'll be looking at some of the functional, reliability, and
> > >> stress tests failures and seeing if there is anything I can help
> > >> with. I'll post to the list for any areas that I pick up.
> > > You can remove IDEA for example... :)
> > I thought Mark was looking at that?
> I thought he just gave an idea about IDEA... probably I'm wrong...
You are both right really. I wasn't working on it but I thought since I
opened the JIRA and suggested a possible solution, people might think I
was ... so this morning I decided not to disappoint anyone and started
looking at it.
Running tests now.
-Mark.
Re: [general] M3 - code frozen
Posted by Alexey Petrenko <al...@gmail.com>.
2007/9/25, Tim Ellison <t....@gmail.com>:
> Alexey Petrenko wrote:
> > 2007/9/25, Tim Ellison <t....@gmail.com>:
> >> I'll be looking at some of the functional, reliability, and stress tests
> >> failures and seeing if there is anything I can help with. I'll post to
> >> the list for any areas that I pick up.
> > You can remove IDEA for example... :)
> I thought Mark was looking at that?
I thought he just gave an idea about IDEA... probably I'm wrong...
SY, Alexey
Re: [general] M3 - code frozen
Posted by Mark Hindess <ma...@googlemail.com>.
On 25 September 2007 at 10:39, Tim Ellison <t....@gmail.com> wrote:
> Alexey Petrenko wrote:
> > 2007/9/25, Tim Ellison <t....@gmail.com>:
> >> I'll be looking at some of the functional, reliability, and stress tests
> >> failures and seeing if there is anything I can help with. I'll post to
> >> the list for any areas that I pick up.
> > You can remove IDEA for example... :)
>
> I thought Mark was looking at that?
I am. (I'm going to check in the source and compiled versions for a
dummy IDEAEngine class. Trying to compile it on-the-fly is horrible to
do properly because of bootstrapping problems and would involve quite a
lot of changes.)
It would be useful if someone could add a page to the website that the
exception message can then point to rather than trying to include the
whole story in an exception message.
-Mark.
Re: [general] M3 - code frozen
Posted by Tim Ellison <t....@gmail.com>.
Alexey Petrenko wrote:
> 2007/9/25, Tim Ellison <t....@gmail.com>:
>> I'll be looking at some of the functional, reliability, and stress tests
>> failures and seeing if there is anything I can help with. I'll post to
>> the list for any areas that I pick up.
> You can remove IDEA for example... :)
I thought Mark was looking at that?
Tim
Re: [general] M3 - code frozen
Posted by Alexey Petrenko <al...@gmail.com>.
2007/9/25, Tim Ellison <t....@gmail.com>:
> I'll be looking at some of the functional, reliability, and stress tests
> failures and seeing if there is anything I can help with. I'll post to
> the list for any areas that I pick up.
You can remove IDEA for example... :)
SY, Alexey
> Stepan Mishura wrote:
> > On 9/24/07, Stepan Mishura <st...@gmail.com> wrote:
> >> On 9/22/07, Stepan Mishura wrote:
> >>> Hi,
> >>>
> >>> According to the plan - Sept. 22 is code freeze date for M3 so let's
> >>> follow policy:
> >>> "no more commits please without agreement from two committers on the dev list."
> >>>
> >>> Let's do more testing and analyze if there any critical/blocker issues
> >>> for consideration.
> >>> Please raise here issues that you think MUST be fixed for M3.
> >> Here is [1] the status of the last snapshot (r578410) that includes
> >> last classlib updates. Unfortunately, not everything is green there.
> >> I'm going to inspect all results to make sure that there are no
> >> failures caused by CC configuration issues.
> >>
> >
> > I've compared testing status for the last snapshot r578410 [1] with M2 [2][3].
> >
> > We have the following short status for failed suites:
> >
> > Windows_x86:
> > * classlib: 2 tests from pack200 module fail on snapshot (but pass
> > on debug build)
> > * Eclipse unit tests 3.2: there is no tests report like for M3. The
> > pass rate was improved from 99.32%[3] to 99.7%[1]
> > * Eclipse unit tests 3.3 are new and the pass rate is 99.77%. I
> > think is acceptable
> > * EGA x48 hours scenario fails. According to [4] it passed on M2.
> > * Functional: need more analysis, currently I see that 2 tests were
> > enabled and new 15 regressions.
> > * Geronimo: 2 regressions
> > * JDK tools: 1 test failed. It might be intermediate failure - the
> > test failed due to timeout
> > * Reliability: 65 tests passed for M2 and 64 for M3. Investigation
> > is required.
> > * Stress: 190 tests passed for M2 and 189 for M3. Investigation is required.
> >
> > Linux_x86:
> > * classlib: 2 tests from pack200 (as for Windows), 1 luni tests
> > failed and 1 crash of security test
> > * Eclipse unit tests 3.2: 2 suites crashed so pass rate is 69.60%. I
> > assume this may be CC host configuration issue. Going to investigate.
> > * Eclipse unit tests 3.3 are new and the pass rate is 96.47%. I
> > think is acceptable
> > * EGA x48 hours scenario: the same as for Windows (scenario fails on M3)
> > * Functional: need more analysis, similar to Windows - some test are
> > passing now but there are new failures.
> > * Geronimo: 2 regressions (the same as for Windows)
> > * Reliability: need more analysis
> > * Stress: need more analysis
> >
> > As I remember Sean took pack200 tests. And Alexei Zakharov took
> > security test crash.
> > I'm going to sort things out with Eclipse unit tests 3.2 crash on
> > Linux. And to look info failed jdktools test.
> >
> > So volunteers are required for: EGAx48, Geronimo, functional,
> > reliability and stress suites.
> >
> > Also we have 2 JIRAs to be resolved for M3 under milstone unmblella[5]:
> > https://issues.apache.org/jira/browse/HARMONY-4844
> > https://issues.apache.org/jira/browse/HARMONY-4810
> >
> > [1] http://people.apache.org/~mloenko/snapshot_testing/script/r578410/index.html
> > [2] http://people.apache.org/~mloenko/snapshot_testing/script/r551077/index.html
> > [3] http://wiki.apache.org/harmony/milestones/M2
> > [4] http://mail-archives.apache.org/mod_mbox/harmony-dev/200706.mbox/%3c678b3f320706290508l554079dau6af1a82b17d62b54@mail.gmail.com%3e
> > [5] https://issues.apache.org/jira/browse/HARMONY-4843
> >
> > Thanks,
> > Stepan.
> >
> >
> >> Please feel free to pick up any issue for investigation. For example,
> >> 2 pack200 classlib test failed. Also there is a crash of
> >> org.apache.harmony.security.tests.java.security.cert.serialization.CertificateTest
> >> on Linux x86
> >>
> >> BTW, should we consider BTI's workspace (that we use for M3 testing)
> >> frozen too?
> >>
> >> [1] http://people.apache.org/~mloenko/snapshot_testing/script/r578410/index.html
> >>
> >> Thanks,
> >> Stepan.
> >
>
Re: [general] M3 - code frozen
Posted by Andrey Yakushev <an...@gmail.com>.
> Thanks for your report. Waiting for real issues analysis.
Analysis details:
9 failures on Windows:
api.kernel.hooks.AddRmPropertiesHooksTest timeout
api.kernel.thread.ThreadArrayTest.ThreadArrayTest
OutOfMemoryError - regression
api.kernel.threadgroup.EnumerateTest
OutOfMemoryError - regression
api.net.DatagramTest timeout
api.net.HttpConnectionTest configuration problem
api.net.SingleConnectTest timeout
api.nio.buffers.ByteBufferallocateTest
IllegalArgumentException - regression
api.serialization.SerializableClassesTest timeout
vm.gc.WeakRefsTest timeout
13 failed on Linux:
api.kernel.exec.RunExec too many files opened
api.kernel.management.SystemResourceOrientedTest vm crash - SIGSEGV
api.kernel.thread.ThreadArrayTest.ThreadArrayTest OutOfMemoryError
api.net.DatagramTest timeout
api.net.HttpConnectionTest configuration problem
api.net.SingleConnectTest address is not
available – busy socket(?)
api.nio.buffers.ByteBufferallocateTest IllegalArgumentException
api.nio.channels.filechannel.FileChannelMapTest timeout
api.nio.channels.filechannel.MappedByteBufferForceTest vm crash - SIGSEGV
api.serialization.SerializableClassesTest timeout
vm.finalization.FinalizeThrowRestoreTest timeout
vm.gc.WeakRefsTest timeout
vm.stack.StackUnwindTest SIGABRT in VM code
So it seems we have 3 regressions on Windows. I will check if we have
all these failures submitted as JIRAs.
Thanks,
Andrey
On 9/25/07, Stepan Mishura <st...@gmail.com> wrote:
> On 9/25/07, Andrey Yakushev <an...@gmail.com> wrote:
> > I also made some analysis for reliability test suite.
> > I've found that several tests didn't fail but rather were killed by
> > guarding timeout.
> >
> > They are:
> > api.nio.channels.filechannel.FileChannelMapTest
> > api.net.DatagramTest
> > vm.finalization.FinalizeThrowRestoreTest
> > vm.gc.WeakRefsTest
> > api.serialization.SerializableClassesTest
> >
> > I think it is due to slowing down of the test host after repeated
> > tests iteration. I suggest increasing the killing timeout. I've opened
> > HARMONY-4851 for this.
>
> I'm OK with increasing timeout.
>
> >
> > I've run excluded reliability tests several times on Windows and Linux
> > and I don't see the failures in the following excluded tests now:
> >
> > api.kernel.thread.Calculation.CalcTest
> > api.kernel.thread.StackTraceTest.StackTraceTest
> > api.nio.charset.ContainsTest
> > api.text.DecimalFormat_Locales
> > api.zip.ZlibTest
> >
> > I suggest removing them from the exclude list. I've opened
> > HARMONY-4850 for this.
> >
>
> I'm OK with the exclude list clean up.
>
> > api.net.HttpConnectionTest fails due to unavailability of
> > harmony.apache.org site from the test host network. It works fine if
> > site is accessible.
> >
>
> Why not to fix the test to be run against local http server (for
> example, jetty)?
>
> > Other failures seem the real reliability issues. These tests fail only
> > after several successful iterations.
> >
>
> Thanks for your report. Waiting for real issues analysis.
>
> Thanks,
> Stepan.
>
> > Thanks,
> > Andrey
> >
> >
> >
> >
> > On 9/25/07, Tim Ellison <t....@gmail.com> wrote:
> > > I'll be looking at some of the functional, reliability, and stress tests
> > > failures and seeing if there is anything I can help with. I'll post to
> > > the list for any areas that I pick up.
> > >
> > > Regards,
> > > Tim
> > >
> > > Stepan Mishura wrote:
> > > > On 9/24/07, Stepan Mishura <st...@gmail.com> wrote:
> > > >> On 9/22/07, Stepan Mishura wrote:
> > > >>> Hi,
> > > >>>
> > > >>> According to the plan - Sept. 22 is code freeze date for M3 so let's
> > > >>> follow policy:
> > > >>> "no more commits please without agreement from two committers on the dev list."
> > > >>>
> > > >>> Let's do more testing and analyze if there any critical/blocker issues
> > > >>> for consideration.
> > > >>> Please raise here issues that you think MUST be fixed for M3.
> > > >> Here is [1] the status of the last snapshot (r578410) that includes
> > > >> last classlib updates. Unfortunately, not everything is green there.
> > > >> I'm going to inspect all results to make sure that there are no
> > > >> failures caused by CC configuration issues.
> > > >>
> > > >
> > > > I've compared testing status for the last snapshot r578410 [1] with M2 [2][3].
> > > >
> > > > We have the following short status for failed suites:
> > > >
> > > > Windows_x86:
> > > > * classlib: 2 tests from pack200 module fail on snapshot (but pass
> > > > on debug build)
> > > > * Eclipse unit tests 3.2: there is no tests report like for M3. The
> > > > pass rate was improved from 99.32%[3] to 99.7%[1]
> > > > * Eclipse unit tests 3.3 are new and the pass rate is 99.77%. I
> > > > think is acceptable
> > > > * EGA x48 hours scenario fails. According to [4] it passed on M2.
> > > > * Functional: need more analysis, currently I see that 2 tests were
> > > > enabled and new 15 regressions.
> > > > * Geronimo: 2 regressions
> > > > * JDK tools: 1 test failed. It might be intermediate failure - the
> > > > test failed due to timeout
> > > > * Reliability: 65 tests passed for M2 and 64 for M3. Investigation
> > > > is required.
> > > > * Stress: 190 tests passed for M2 and 189 for M3. Investigation is required.
> > > >
> > > > Linux_x86:
> > > > * classlib: 2 tests from pack200 (as for Windows), 1 luni tests
> > > > failed and 1 crash of security test
> > > > * Eclipse unit tests 3.2: 2 suites crashed so pass rate is 69.60%. I
> > > > assume this may be CC host configuration issue. Going to investigate.
> > > > * Eclipse unit tests 3.3 are new and the pass rate is 96.47%. I
> > > > think is acceptable
> > > > * EGA x48 hours scenario: the same as for Windows (scenario fails on M3)
> > > > * Functional: need more analysis, similar to Windows - some test are
> > > > passing now but there are new failures.
> > > > * Geronimo: 2 regressions (the same as for Windows)
> > > > * Reliability: need more analysis
> > > > * Stress: need more analysis
> > > >
> > > > As I remember Sean took pack200 tests. And Alexei Zakharov took
> > > > security test crash.
> > > > I'm going to sort things out with Eclipse unit tests 3.2 crash on
> > > > Linux. And to look info failed jdktools test.
> > > >
> > > > So volunteers are required for: EGAx48, Geronimo, functional,
> > > > reliability and stress suites.
> > > >
> > > > Also we have 2 JIRAs to be resolved for M3 under milstone unmblella[5]:
> > > > https://issues.apache.org/jira/browse/HARMONY-4844
> > > > https://issues.apache.org/jira/browse/HARMONY-4810
> > > >
> > > > [1] http://people.apache.org/~mloenko/snapshot_testing/script/r578410/index.html
> > > > [2] http://people.apache.org/~mloenko/snapshot_testing/script/r551077/index.html
> > > > [3] http://wiki.apache.org/harmony/milestones/M2
> > > > [4] http://mail-archives.apache.org/mod_mbox/harmony-dev/200706.mbox/%3c678b3f320706290508l554079dau6af1a82b17d62b54@mail.gmail.com%3e
> > > > [5] https://issues.apache.org/jira/browse/HARMONY-4843
> > > >
> > > > Thanks,
> > > > Stepan.
> > > >
> > > >
> > > >> Please feel free to pick up any issue for investigation. For example,
> > > >> 2 pack200 classlib test failed. Also there is a crash of
> > > >> org.apache.harmony.security.tests.java.security.cert.serialization.CertificateTest
> > > >> on Linux x86
> > > >>
> > > >> BTW, should we consider BTI's workspace (that we use for M3 testing)
> > > >> frozen too?
> > > >>
> > > >> [1] http://people.apache.org/~mloenko/snapshot_testing/script/r578410/index.html
> > > >>
> > > >> Thanks,
> > > >> Stepan.
> > > >
> > >
> >
> >
> > --
> > Thanks,
> > Andrey
>
--
Thanks,
Andrey
Re: [general] M3 - code frozen
Posted by Stepan Mishura <st...@gmail.com>.
On 9/25/07, Andrey Yakushev <an...@gmail.com> wrote:
> I also made some analysis for reliability test suite.
> I've found that several tests didn't fail but rather were killed by
> guarding timeout.
>
> They are:
> api.nio.channels.filechannel.FileChannelMapTest
> api.net.DatagramTest
> vm.finalization.FinalizeThrowRestoreTest
> vm.gc.WeakRefsTest
> api.serialization.SerializableClassesTest
>
> I think it is due to slowing down of the test host after repeated
> tests iteration. I suggest increasing the killing timeout. I've opened
> HARMONY-4851 for this.
I'm OK with increasing timeout.
>
> I've run excluded reliability tests several times on Windows and Linux
> and I don't see the failures in the following excluded tests now:
>
> api.kernel.thread.Calculation.CalcTest
> api.kernel.thread.StackTraceTest.StackTraceTest
> api.nio.charset.ContainsTest
> api.text.DecimalFormat_Locales
> api.zip.ZlibTest
>
> I suggest removing them from the exclude list. I've opened
> HARMONY-4850 for this.
>
I'm OK with the exclude list clean up.
> api.net.HttpConnectionTest fails due to unavailability of
> harmony.apache.org site from the test host network. It works fine if
> site is accessible.
>
Why not to fix the test to be run against local http server (for
example, jetty)?
> Other failures seem the real reliability issues. These tests fail only
> after several successful iterations.
>
Thanks for your report. Waiting for real issues analysis.
Thanks,
Stepan.
> Thanks,
> Andrey
>
>
>
>
> On 9/25/07, Tim Ellison <t....@gmail.com> wrote:
> > I'll be looking at some of the functional, reliability, and stress tests
> > failures and seeing if there is anything I can help with. I'll post to
> > the list for any areas that I pick up.
> >
> > Regards,
> > Tim
> >
> > Stepan Mishura wrote:
> > > On 9/24/07, Stepan Mishura <st...@gmail.com> wrote:
> > >> On 9/22/07, Stepan Mishura wrote:
> > >>> Hi,
> > >>>
> > >>> According to the plan - Sept. 22 is code freeze date for M3 so let's
> > >>> follow policy:
> > >>> "no more commits please without agreement from two committers on the dev list."
> > >>>
> > >>> Let's do more testing and analyze if there any critical/blocker issues
> > >>> for consideration.
> > >>> Please raise here issues that you think MUST be fixed for M3.
> > >> Here is [1] the status of the last snapshot (r578410) that includes
> > >> last classlib updates. Unfortunately, not everything is green there.
> > >> I'm going to inspect all results to make sure that there are no
> > >> failures caused by CC configuration issues.
> > >>
> > >
> > > I've compared testing status for the last snapshot r578410 [1] with M2 [2][3].
> > >
> > > We have the following short status for failed suites:
> > >
> > > Windows_x86:
> > > * classlib: 2 tests from pack200 module fail on snapshot (but pass
> > > on debug build)
> > > * Eclipse unit tests 3.2: there is no tests report like for M3. The
> > > pass rate was improved from 99.32%[3] to 99.7%[1]
> > > * Eclipse unit tests 3.3 are new and the pass rate is 99.77%. I
> > > think is acceptable
> > > * EGA x48 hours scenario fails. According to [4] it passed on M2.
> > > * Functional: need more analysis, currently I see that 2 tests were
> > > enabled and new 15 regressions.
> > > * Geronimo: 2 regressions
> > > * JDK tools: 1 test failed. It might be intermediate failure - the
> > > test failed due to timeout
> > > * Reliability: 65 tests passed for M2 and 64 for M3. Investigation
> > > is required.
> > > * Stress: 190 tests passed for M2 and 189 for M3. Investigation is required.
> > >
> > > Linux_x86:
> > > * classlib: 2 tests from pack200 (as for Windows), 1 luni tests
> > > failed and 1 crash of security test
> > > * Eclipse unit tests 3.2: 2 suites crashed so pass rate is 69.60%. I
> > > assume this may be CC host configuration issue. Going to investigate.
> > > * Eclipse unit tests 3.3 are new and the pass rate is 96.47%. I
> > > think is acceptable
> > > * EGA x48 hours scenario: the same as for Windows (scenario fails on M3)
> > > * Functional: need more analysis, similar to Windows - some test are
> > > passing now but there are new failures.
> > > * Geronimo: 2 regressions (the same as for Windows)
> > > * Reliability: need more analysis
> > > * Stress: need more analysis
> > >
> > > As I remember Sean took pack200 tests. And Alexei Zakharov took
> > > security test crash.
> > > I'm going to sort things out with Eclipse unit tests 3.2 crash on
> > > Linux. And to look info failed jdktools test.
> > >
> > > So volunteers are required for: EGAx48, Geronimo, functional,
> > > reliability and stress suites.
> > >
> > > Also we have 2 JIRAs to be resolved for M3 under milstone unmblella[5]:
> > > https://issues.apache.org/jira/browse/HARMONY-4844
> > > https://issues.apache.org/jira/browse/HARMONY-4810
> > >
> > > [1] http://people.apache.org/~mloenko/snapshot_testing/script/r578410/index.html
> > > [2] http://people.apache.org/~mloenko/snapshot_testing/script/r551077/index.html
> > > [3] http://wiki.apache.org/harmony/milestones/M2
> > > [4] http://mail-archives.apache.org/mod_mbox/harmony-dev/200706.mbox/%3c678b3f320706290508l554079dau6af1a82b17d62b54@mail.gmail.com%3e
> > > [5] https://issues.apache.org/jira/browse/HARMONY-4843
> > >
> > > Thanks,
> > > Stepan.
> > >
> > >
> > >> Please feel free to pick up any issue for investigation. For example,
> > >> 2 pack200 classlib test failed. Also there is a crash of
> > >> org.apache.harmony.security.tests.java.security.cert.serialization.CertificateTest
> > >> on Linux x86
> > >>
> > >> BTW, should we consider BTI's workspace (that we use for M3 testing)
> > >> frozen too?
> > >>
> > >> [1] http://people.apache.org/~mloenko/snapshot_testing/script/r578410/index.html
> > >>
> > >> Thanks,
> > >> Stepan.
> > >
> >
>
>
> --
> Thanks,
> Andrey
Re: [general] M3 - code frozen
Posted by Andrey Yakushev <an...@gmail.com>.
I also made some analysis for reliability test suite.
I've found that several tests didn't fail but rather were killed by
guarding timeout.
They are:
api.nio.channels.filechannel.FileChannelMapTest
api.net.DatagramTest
vm.finalization.FinalizeThrowRestoreTest
vm.gc.WeakRefsTest
api.serialization.SerializableClassesTest
I think it is due to slowing down of the test host after repeated
tests iteration. I suggest increasing the killing timeout. I've opened
HARMONY-4851 for this.
I've run excluded reliability tests several times on Windows and Linux
and I don't see the failures in the following excluded tests now:
api.kernel.thread.Calculation.CalcTest
api.kernel.thread.StackTraceTest.StackTraceTest
api.nio.charset.ContainsTest
api.text.DecimalFormat_Locales
api.zip.ZlibTest
I suggest removing them from the exclude list. I've opened
HARMONY-4850 for this.
api.net.HttpConnectionTest fails due to unavailability of
harmony.apache.org site from the test host network. It works fine if
site is accessible.
Other failures seem the real reliability issues. These tests fail only
after several successful iterations.
Thanks,
Andrey
On 9/25/07, Tim Ellison <t....@gmail.com> wrote:
> I'll be looking at some of the functional, reliability, and stress tests
> failures and seeing if there is anything I can help with. I'll post to
> the list for any areas that I pick up.
>
> Regards,
> Tim
>
> Stepan Mishura wrote:
> > On 9/24/07, Stepan Mishura <st...@gmail.com> wrote:
> >> On 9/22/07, Stepan Mishura wrote:
> >>> Hi,
> >>>
> >>> According to the plan - Sept. 22 is code freeze date for M3 so let's
> >>> follow policy:
> >>> "no more commits please without agreement from two committers on the dev list."
> >>>
> >>> Let's do more testing and analyze if there any critical/blocker issues
> >>> for consideration.
> >>> Please raise here issues that you think MUST be fixed for M3.
> >> Here is [1] the status of the last snapshot (r578410) that includes
> >> last classlib updates. Unfortunately, not everything is green there.
> >> I'm going to inspect all results to make sure that there are no
> >> failures caused by CC configuration issues.
> >>
> >
> > I've compared testing status for the last snapshot r578410 [1] with M2 [2][3].
> >
> > We have the following short status for failed suites:
> >
> > Windows_x86:
> > * classlib: 2 tests from pack200 module fail on snapshot (but pass
> > on debug build)
> > * Eclipse unit tests 3.2: there is no tests report like for M3. The
> > pass rate was improved from 99.32%[3] to 99.7%[1]
> > * Eclipse unit tests 3.3 are new and the pass rate is 99.77%. I
> > think is acceptable
> > * EGA x48 hours scenario fails. According to [4] it passed on M2.
> > * Functional: need more analysis, currently I see that 2 tests were
> > enabled and new 15 regressions.
> > * Geronimo: 2 regressions
> > * JDK tools: 1 test failed. It might be intermediate failure - the
> > test failed due to timeout
> > * Reliability: 65 tests passed for M2 and 64 for M3. Investigation
> > is required.
> > * Stress: 190 tests passed for M2 and 189 for M3. Investigation is required.
> >
> > Linux_x86:
> > * classlib: 2 tests from pack200 (as for Windows), 1 luni tests
> > failed and 1 crash of security test
> > * Eclipse unit tests 3.2: 2 suites crashed so pass rate is 69.60%. I
> > assume this may be CC host configuration issue. Going to investigate.
> > * Eclipse unit tests 3.3 are new and the pass rate is 96.47%. I
> > think is acceptable
> > * EGA x48 hours scenario: the same as for Windows (scenario fails on M3)
> > * Functional: need more analysis, similar to Windows - some test are
> > passing now but there are new failures.
> > * Geronimo: 2 regressions (the same as for Windows)
> > * Reliability: need more analysis
> > * Stress: need more analysis
> >
> > As I remember Sean took pack200 tests. And Alexei Zakharov took
> > security test crash.
> > I'm going to sort things out with Eclipse unit tests 3.2 crash on
> > Linux. And to look info failed jdktools test.
> >
> > So volunteers are required for: EGAx48, Geronimo, functional,
> > reliability and stress suites.
> >
> > Also we have 2 JIRAs to be resolved for M3 under milstone unmblella[5]:
> > https://issues.apache.org/jira/browse/HARMONY-4844
> > https://issues.apache.org/jira/browse/HARMONY-4810
> >
> > [1] http://people.apache.org/~mloenko/snapshot_testing/script/r578410/index.html
> > [2] http://people.apache.org/~mloenko/snapshot_testing/script/r551077/index.html
> > [3] http://wiki.apache.org/harmony/milestones/M2
> > [4] http://mail-archives.apache.org/mod_mbox/harmony-dev/200706.mbox/%3c678b3f320706290508l554079dau6af1a82b17d62b54@mail.gmail.com%3e
> > [5] https://issues.apache.org/jira/browse/HARMONY-4843
> >
> > Thanks,
> > Stepan.
> >
> >
> >> Please feel free to pick up any issue for investigation. For example,
> >> 2 pack200 classlib test failed. Also there is a crash of
> >> org.apache.harmony.security.tests.java.security.cert.serialization.CertificateTest
> >> on Linux x86
> >>
> >> BTW, should we consider BTI's workspace (that we use for M3 testing)
> >> frozen too?
> >>
> >> [1] http://people.apache.org/~mloenko/snapshot_testing/script/r578410/index.html
> >>
> >> Thanks,
> >> Stepan.
> >
>
--
Thanks,
Andrey
Re: [general] M3 - code frozen
Posted by Tim Ellison <t....@gmail.com>.
I'll be looking at some of the functional, reliability, and stress tests
failures and seeing if there is anything I can help with. I'll post to
the list for any areas that I pick up.
Regards,
Tim
Stepan Mishura wrote:
> On 9/24/07, Stepan Mishura <st...@gmail.com> wrote:
>> On 9/22/07, Stepan Mishura wrote:
>>> Hi,
>>>
>>> According to the plan - Sept. 22 is code freeze date for M3 so let's
>>> follow policy:
>>> "no more commits please without agreement from two committers on the dev list."
>>>
>>> Let's do more testing and analyze if there any critical/blocker issues
>>> for consideration.
>>> Please raise here issues that you think MUST be fixed for M3.
>> Here is [1] the status of the last snapshot (r578410) that includes
>> last classlib updates. Unfortunately, not everything is green there.
>> I'm going to inspect all results to make sure that there are no
>> failures caused by CC configuration issues.
>>
>
> I've compared testing status for the last snapshot r578410 [1] with M2 [2][3].
>
> We have the following short status for failed suites:
>
> Windows_x86:
> * classlib: 2 tests from pack200 module fail on snapshot (but pass
> on debug build)
> * Eclipse unit tests 3.2: there is no tests report like for M3. The
> pass rate was improved from 99.32%[3] to 99.7%[1]
> * Eclipse unit tests 3.3 are new and the pass rate is 99.77%. I
> think is acceptable
> * EGA x48 hours scenario fails. According to [4] it passed on M2.
> * Functional: need more analysis, currently I see that 2 tests were
> enabled and new 15 regressions.
> * Geronimo: 2 regressions
> * JDK tools: 1 test failed. It might be intermediate failure - the
> test failed due to timeout
> * Reliability: 65 tests passed for M2 and 64 for M3. Investigation
> is required.
> * Stress: 190 tests passed for M2 and 189 for M3. Investigation is required.
>
> Linux_x86:
> * classlib: 2 tests from pack200 (as for Windows), 1 luni tests
> failed and 1 crash of security test
> * Eclipse unit tests 3.2: 2 suites crashed so pass rate is 69.60%. I
> assume this may be CC host configuration issue. Going to investigate.
> * Eclipse unit tests 3.3 are new and the pass rate is 96.47%. I
> think is acceptable
> * EGA x48 hours scenario: the same as for Windows (scenario fails on M3)
> * Functional: need more analysis, similar to Windows - some test are
> passing now but there are new failures.
> * Geronimo: 2 regressions (the same as for Windows)
> * Reliability: need more analysis
> * Stress: need more analysis
>
> As I remember Sean took pack200 tests. And Alexei Zakharov took
> security test crash.
> I'm going to sort things out with Eclipse unit tests 3.2 crash on
> Linux. And to look info failed jdktools test.
>
> So volunteers are required for: EGAx48, Geronimo, functional,
> reliability and stress suites.
>
> Also we have 2 JIRAs to be resolved for M3 under milstone unmblella[5]:
> https://issues.apache.org/jira/browse/HARMONY-4844
> https://issues.apache.org/jira/browse/HARMONY-4810
>
> [1] http://people.apache.org/~mloenko/snapshot_testing/script/r578410/index.html
> [2] http://people.apache.org/~mloenko/snapshot_testing/script/r551077/index.html
> [3] http://wiki.apache.org/harmony/milestones/M2
> [4] http://mail-archives.apache.org/mod_mbox/harmony-dev/200706.mbox/%3c678b3f320706290508l554079dau6af1a82b17d62b54@mail.gmail.com%3e
> [5] https://issues.apache.org/jira/browse/HARMONY-4843
>
> Thanks,
> Stepan.
>
>
>> Please feel free to pick up any issue for investigation. For example,
>> 2 pack200 classlib test failed. Also there is a crash of
>> org.apache.harmony.security.tests.java.security.cert.serialization.CertificateTest
>> on Linux x86
>>
>> BTW, should we consider BTI's workspace (that we use for M3 testing)
>> frozen too?
>>
>> [1] http://people.apache.org/~mloenko/snapshot_testing/script/r578410/index.html
>>
>> Thanks,
>> Stepan.
>
Re: [general] M3 - code frozen
Posted by Sian January <si...@googlemail.com>.
Great - I'm glad that's sorted out.
On 25/09/2007, Stepan Mishura <st...@gmail.com> wrote:
>
> On 9/25/07, Sian January <si...@googlemail.com> wrote:
> > The pack200 tests are passing reliably on my machine, and I have just
> run
> > them on DRLVM as well as the IBM VME to make sure. However I know the
> > recent changes that went in caused test failures the first time for
> > Tim because of some signature changes, and needed a 'clean' before the
> build
> > before they would pass. Could this be the case with the snapshot, or
> was it
> > definitely a clean build?
>
> Yes, you are right Sian. Good catch!
> I'm going to fix the adaptor for classlib-tests.
>
> Thanks,
> Stepan.
>
> >
> > Thanks,
> >
> > Sian
> >
> >
> >
> > On 25/09/2007, Stepan Mishura <st...@gmail.com> wrote:
> > >
> > > On 9/24/07, Stepan Mishura <st...@gmail.com> wrote:
> > > > On 9/22/07, Stepan Mishura wrote:
> > > > > Hi,
> > > > >
> > > > > According to the plan - Sept. 22 is code freeze date for M3 so
> let's
> > > > > follow policy:
> > > > > "no more commits please without agreement from two committers on
> the
> > > dev list."
> > > > >
> > > > > Let's do more testing and analyze if there any critical/blocker
> issues
> > > > > for consideration.
> > > > > Please raise here issues that you think MUST be fixed for M3.
> > > >
> > > > Here is [1] the status of the last snapshot (r578410) that includes
> > > > last classlib updates. Unfortunately, not everything is green there.
> > > > I'm going to inspect all results to make sure that there are no
> > > > failures caused by CC configuration issues.
> > > >
> > >
> > > I've compared testing status for the last snapshot r578410 [1] with M2
> > > [2][3].
> > >
> > > We have the following short status for failed suites:
> > >
> > > Windows_x86:
> > > * classlib: 2 tests from pack200 module fail on snapshot (but pass
> > > on debug build)
> > > * Eclipse unit tests 3.2: there is no tests report like for M3. The
> > > pass rate was improved from 99.32%[3] to 99.7%[1]
> > > * Eclipse unit tests 3.3 are new and the pass rate is 99.77%. I
> > > think is acceptable
> > > * EGA x48 hours scenario fails. According to [4] it passed on M2.
> > > * Functional: need more analysis, currently I see that 2 tests were
> > > enabled and new 15 regressions.
> > > * Geronimo: 2 regressions
> > > * JDK tools: 1 test failed. It might be intermediate failure - the
> > > test failed due to timeout
> > > * Reliability: 65 tests passed for M2 and 64 for M3. Investigation
> > > is required.
> > > * Stress: 190 tests passed for M2 and 189 for M3. Investigation is
> > > required.
> > >
> > > Linux_x86:
> > > * classlib: 2 tests from pack200 (as for Windows), 1 luni tests
> > > failed and 1 crash of security test
> > > * Eclipse unit tests 3.2: 2 suites crashed so pass rate is 69.60%. I
> > > assume this may be CC host configuration issue. Going to investigate.
> > > * Eclipse unit tests 3.3 are new and the pass rate is 96.47%. I
> > > think is acceptable
> > > * EGA x48 hours scenario: the same as for Windows (scenario fails on
> M3)
> > > * Functional: need more analysis, similar to Windows - some test are
> > > passing now but there are new failures.
> > > * Geronimo: 2 regressions (the same as for Windows)
> > > * Reliability: need more analysis
> > > * Stress: need more analysis
> > >
> > > As I remember Sean took pack200 tests. And Alexei Zakharov took
> > > security test crash.
> > > I'm going to sort things out with Eclipse unit tests 3.2 crash on
> > > Linux. And to look info failed jdktools test.
> > >
> > > So volunteers are required for: EGAx48, Geronimo, functional,
> > > reliability and stress suites.
> > >
> > > Also we have 2 JIRAs to be resolved for M3 under milstone
> unmblella[5]:
> > > https://issues.apache.org/jira/browse/HARMONY-4844
> > > https://issues.apache.org/jira/browse/HARMONY-4810
> > >
> > > [1]
> > >
> http://people.apache.org/~mloenko/snapshot_testing/script/r578410/index.html
> > > [2]
> > >
> http://people.apache.org/~mloenko/snapshot_testing/script/r551077/index.html
> > > [3] http://wiki.apache.org/harmony/milestones/M2
> > > [4]
> > >
> http://mail-archives.apache.org/mod_mbox/harmony-dev/200706.mbox/%3c678b3f320706290508l554079dau6af1a82b17d62b54@mail.gmail.com%3e
> > > [5] https://issues.apache.org/jira/browse/HARMONY-4843
> > >
> > > Thanks,
> > > Stepan.
> > >
> > >
> > > > Please feel free to pick up any issue for investigation. For
> example,
> > > > 2 pack200 classlib test failed. Also there is a crash of
> > > >
> > >
> org.apache.harmony.security.tests.java.security.cert.serialization.CertificateTest
> > > > on Linux x86
> > > >
> > > > BTW, should we consider BTI's workspace (that we use for M3 testing)
> > > > frozen too?
> > > >
> > > > [1]
> > >
> http://people.apache.org/~mloenko/snapshot_testing/script/r578410/index.html
> > > >
> > > > Thanks,
> > > > Stepan.
> > >
> >
> >
> >
> > --
> > Unless stated otherwise above:
> > IBM United Kingdom Limited - Registered in England and Wales with number
> > 741598.
> > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
> 3AU
>
--
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Re: [general] M3 - code frozen
Posted by Stepan Mishura <st...@gmail.com>.
On 9/25/07, Sian January <si...@googlemail.com> wrote:
> The pack200 tests are passing reliably on my machine, and I have just run
> them on DRLVM as well as the IBM VME to make sure. However I know the
> recent changes that went in caused test failures the first time for
> Tim because of some signature changes, and needed a 'clean' before the build
> before they would pass. Could this be the case with the snapshot, or was it
> definitely a clean build?
Yes, you are right Sian. Good catch!
I'm going to fix the adaptor for classlib-tests.
Thanks,
Stepan.
>
> Thanks,
>
> Sian
>
>
>
> On 25/09/2007, Stepan Mishura <st...@gmail.com> wrote:
> >
> > On 9/24/07, Stepan Mishura <st...@gmail.com> wrote:
> > > On 9/22/07, Stepan Mishura wrote:
> > > > Hi,
> > > >
> > > > According to the plan - Sept. 22 is code freeze date for M3 so let's
> > > > follow policy:
> > > > "no more commits please without agreement from two committers on the
> > dev list."
> > > >
> > > > Let's do more testing and analyze if there any critical/blocker issues
> > > > for consideration.
> > > > Please raise here issues that you think MUST be fixed for M3.
> > >
> > > Here is [1] the status of the last snapshot (r578410) that includes
> > > last classlib updates. Unfortunately, not everything is green there.
> > > I'm going to inspect all results to make sure that there are no
> > > failures caused by CC configuration issues.
> > >
> >
> > I've compared testing status for the last snapshot r578410 [1] with M2
> > [2][3].
> >
> > We have the following short status for failed suites:
> >
> > Windows_x86:
> > * classlib: 2 tests from pack200 module fail on snapshot (but pass
> > on debug build)
> > * Eclipse unit tests 3.2: there is no tests report like for M3. The
> > pass rate was improved from 99.32%[3] to 99.7%[1]
> > * Eclipse unit tests 3.3 are new and the pass rate is 99.77%. I
> > think is acceptable
> > * EGA x48 hours scenario fails. According to [4] it passed on M2.
> > * Functional: need more analysis, currently I see that 2 tests were
> > enabled and new 15 regressions.
> > * Geronimo: 2 regressions
> > * JDK tools: 1 test failed. It might be intermediate failure - the
> > test failed due to timeout
> > * Reliability: 65 tests passed for M2 and 64 for M3. Investigation
> > is required.
> > * Stress: 190 tests passed for M2 and 189 for M3. Investigation is
> > required.
> >
> > Linux_x86:
> > * classlib: 2 tests from pack200 (as for Windows), 1 luni tests
> > failed and 1 crash of security test
> > * Eclipse unit tests 3.2: 2 suites crashed so pass rate is 69.60%. I
> > assume this may be CC host configuration issue. Going to investigate.
> > * Eclipse unit tests 3.3 are new and the pass rate is 96.47%. I
> > think is acceptable
> > * EGA x48 hours scenario: the same as for Windows (scenario fails on M3)
> > * Functional: need more analysis, similar to Windows - some test are
> > passing now but there are new failures.
> > * Geronimo: 2 regressions (the same as for Windows)
> > * Reliability: need more analysis
> > * Stress: need more analysis
> >
> > As I remember Sean took pack200 tests. And Alexei Zakharov took
> > security test crash.
> > I'm going to sort things out with Eclipse unit tests 3.2 crash on
> > Linux. And to look info failed jdktools test.
> >
> > So volunteers are required for: EGAx48, Geronimo, functional,
> > reliability and stress suites.
> >
> > Also we have 2 JIRAs to be resolved for M3 under milstone unmblella[5]:
> > https://issues.apache.org/jira/browse/HARMONY-4844
> > https://issues.apache.org/jira/browse/HARMONY-4810
> >
> > [1]
> > http://people.apache.org/~mloenko/snapshot_testing/script/r578410/index.html
> > [2]
> > http://people.apache.org/~mloenko/snapshot_testing/script/r551077/index.html
> > [3] http://wiki.apache.org/harmony/milestones/M2
> > [4]
> > http://mail-archives.apache.org/mod_mbox/harmony-dev/200706.mbox/%3c678b3f320706290508l554079dau6af1a82b17d62b54@mail.gmail.com%3e
> > [5] https://issues.apache.org/jira/browse/HARMONY-4843
> >
> > Thanks,
> > Stepan.
> >
> >
> > > Please feel free to pick up any issue for investigation. For example,
> > > 2 pack200 classlib test failed. Also there is a crash of
> > >
> > org.apache.harmony.security.tests.java.security.cert.serialization.CertificateTest
> > > on Linux x86
> > >
> > > BTW, should we consider BTI's workspace (that we use for M3 testing)
> > > frozen too?
> > >
> > > [1]
> > http://people.apache.org/~mloenko/snapshot_testing/script/r578410/index.html
> > >
> > > Thanks,
> > > Stepan.
> >
>
>
>
> --
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Re: [general] M3 - code frozen
Posted by Sian January <si...@googlemail.com>.
The pack200 tests are passing reliably on my machine, and I have just run
them on DRLVM as well as the IBM VME to make sure. However I know the
recent changes that went in caused test failures the first time for
Tim because of some signature changes, and needed a 'clean' before the build
before they would pass. Could this be the case with the snapshot, or was it
definitely a clean build?
Thanks,
Sian
On 25/09/2007, Stepan Mishura <st...@gmail.com> wrote:
>
> On 9/24/07, Stepan Mishura <st...@gmail.com> wrote:
> > On 9/22/07, Stepan Mishura wrote:
> > > Hi,
> > >
> > > According to the plan - Sept. 22 is code freeze date for M3 so let's
> > > follow policy:
> > > "no more commits please without agreement from two committers on the
> dev list."
> > >
> > > Let's do more testing and analyze if there any critical/blocker issues
> > > for consideration.
> > > Please raise here issues that you think MUST be fixed for M3.
> >
> > Here is [1] the status of the last snapshot (r578410) that includes
> > last classlib updates. Unfortunately, not everything is green there.
> > I'm going to inspect all results to make sure that there are no
> > failures caused by CC configuration issues.
> >
>
> I've compared testing status for the last snapshot r578410 [1] with M2
> [2][3].
>
> We have the following short status for failed suites:
>
> Windows_x86:
> * classlib: 2 tests from pack200 module fail on snapshot (but pass
> on debug build)
> * Eclipse unit tests 3.2: there is no tests report like for M3. The
> pass rate was improved from 99.32%[3] to 99.7%[1]
> * Eclipse unit tests 3.3 are new and the pass rate is 99.77%. I
> think is acceptable
> * EGA x48 hours scenario fails. According to [4] it passed on M2.
> * Functional: need more analysis, currently I see that 2 tests were
> enabled and new 15 regressions.
> * Geronimo: 2 regressions
> * JDK tools: 1 test failed. It might be intermediate failure - the
> test failed due to timeout
> * Reliability: 65 tests passed for M2 and 64 for M3. Investigation
> is required.
> * Stress: 190 tests passed for M2 and 189 for M3. Investigation is
> required.
>
> Linux_x86:
> * classlib: 2 tests from pack200 (as for Windows), 1 luni tests
> failed and 1 crash of security test
> * Eclipse unit tests 3.2: 2 suites crashed so pass rate is 69.60%. I
> assume this may be CC host configuration issue. Going to investigate.
> * Eclipse unit tests 3.3 are new and the pass rate is 96.47%. I
> think is acceptable
> * EGA x48 hours scenario: the same as for Windows (scenario fails on M3)
> * Functional: need more analysis, similar to Windows - some test are
> passing now but there are new failures.
> * Geronimo: 2 regressions (the same as for Windows)
> * Reliability: need more analysis
> * Stress: need more analysis
>
> As I remember Sean took pack200 tests. And Alexei Zakharov took
> security test crash.
> I'm going to sort things out with Eclipse unit tests 3.2 crash on
> Linux. And to look info failed jdktools test.
>
> So volunteers are required for: EGAx48, Geronimo, functional,
> reliability and stress suites.
>
> Also we have 2 JIRAs to be resolved for M3 under milstone unmblella[5]:
> https://issues.apache.org/jira/browse/HARMONY-4844
> https://issues.apache.org/jira/browse/HARMONY-4810
>
> [1]
> http://people.apache.org/~mloenko/snapshot_testing/script/r578410/index.html
> [2]
> http://people.apache.org/~mloenko/snapshot_testing/script/r551077/index.html
> [3] http://wiki.apache.org/harmony/milestones/M2
> [4]
> http://mail-archives.apache.org/mod_mbox/harmony-dev/200706.mbox/%3c678b3f320706290508l554079dau6af1a82b17d62b54@mail.gmail.com%3e
> [5] https://issues.apache.org/jira/browse/HARMONY-4843
>
> Thanks,
> Stepan.
>
>
> > Please feel free to pick up any issue for investigation. For example,
> > 2 pack200 classlib test failed. Also there is a crash of
> >
> org.apache.harmony.security.tests.java.security.cert.serialization.CertificateTest
> > on Linux x86
> >
> > BTW, should we consider BTI's workspace (that we use for M3 testing)
> > frozen too?
> >
> > [1]
> http://people.apache.org/~mloenko/snapshot_testing/script/r578410/index.html
> >
> > Thanks,
> > Stepan.
>
--
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Re: [general] M3 - code frozen
Posted by Stepan Mishura <st...@gmail.com>.
On 9/25/07, Gregory Shimansky <gs...@gmail.com> wrote:
> Alexey Varlamov wrote:
> > Guys,
> >
> > Probably I'd articulate it more clearly :), but there is an issue
> > HARMONY-4844 "[build] Wrong hythr.lib copied to federated build" which
> > affects drlvm-tests run on snapshots. You might noticed strange number
> > of drlvm tests for Windows builds due to this. Not a big deal per se,
> > but it seems we already target new milestone candidate and it would be
> > better to apply this fix too to get correct results for next snapshot.
>
> +1 to commit. The patch looks totally harmless to me.
OK. I'm going to commit it.
-Stepan.
>
> > 2007/9/25, Alexei Zakharov <al...@gmail.com>:
> >>> As I remember Sean took pack200 tests. And Alexei Zakharov took
> >>> security test crash.
> >> I've just said I'm able to reproduce failures :) However, I'll take a
> >> look. May be it can be fixed easily.
> >>
> >> Regards,
> >> Alexei
> >>
> >> 2007/9/25, Stepan Mishura <st...@gmail.com>:
> >>> On 9/24/07, Stepan Mishura <st...@gmail.com> wrote:
> >>>> On 9/22/07, Stepan Mishura wrote:
> >>>>> Hi,
> >>>>>
> >>>>> According to the plan - Sept. 22 is code freeze date for M3 so let's
> >>>>> follow policy:
> >>>>> "no more commits please without agreement from two committers on the dev list."
> >>>>>
> >>>>> Let's do more testing and analyze if there any critical/blocker issues
> >>>>> for consideration.
> >>>>> Please raise here issues that you think MUST be fixed for M3.
> >>>> Here is [1] the status of the last snapshot (r578410) that includes
> >>>> last classlib updates. Unfortunately, not everything is green there.
> >>>> I'm going to inspect all results to make sure that there are no
> >>>> failures caused by CC configuration issues.
> >>>>
> >>> I've compared testing status for the last snapshot r578410 [1] with M2 [2][3].
> >>>
> >>> We have the following short status for failed suites:
> >>>
> >>> Windows_x86:
> >>> * classlib: 2 tests from pack200 module fail on snapshot (but pass
> >>> on debug build)
> >>> * Eclipse unit tests 3.2: there is no tests report like for M3. The
> >>> pass rate was improved from 99.32%[3] to 99.7%[1]
> >>> * Eclipse unit tests 3.3 are new and the pass rate is 99.77%. I
> >>> think is acceptable
> >>> * EGA x48 hours scenario fails. According to [4] it passed on M2.
> >>> * Functional: need more analysis, currently I see that 2 tests were
> >>> enabled and new 15 regressions.
> >>> * Geronimo: 2 regressions
> >>> * JDK tools: 1 test failed. It might be intermediate failure - the
> >>> test failed due to timeout
> >>> * Reliability: 65 tests passed for M2 and 64 for M3. Investigation
> >>> is required.
> >>> * Stress: 190 tests passed for M2 and 189 for M3. Investigation is required.
> >>>
> >>> Linux_x86:
> >>> * classlib: 2 tests from pack200 (as for Windows), 1 luni tests
> >>> failed and 1 crash of security test
> >>> * Eclipse unit tests 3.2: 2 suites crashed so pass rate is 69.60%. I
> >>> assume this may be CC host configuration issue. Going to investigate.
> >>> * Eclipse unit tests 3.3 are new and the pass rate is 96.47%. I
> >>> think is acceptable
> >>> * EGA x48 hours scenario: the same as for Windows (scenario fails on M3)
> >>> * Functional: need more analysis, similar to Windows - some test are
> >>> passing now but there are new failures.
> >>> * Geronimo: 2 regressions (the same as for Windows)
> >>> * Reliability: need more analysis
> >>> * Stress: need more analysis
> >>>
> >>> As I remember Sean took pack200 tests. And Alexei Zakharov took
> >>> security test crash.
> >>> I'm going to sort things out with Eclipse unit tests 3.2 crash on
> >>> Linux. And to look info failed jdktools test.
> >>>
> >>> So volunteers are required for: EGAx48, Geronimo, functional,
> >>> reliability and stress suites.
> >>>
> >>> Also we have 2 JIRAs to be resolved for M3 under milstone unmblella[5]:
> >>> https://issues.apache.org/jira/browse/HARMONY-4844
> >>> https://issues.apache.org/jira/browse/HARMONY-4810
> >>>
> >>> [1] http://people.apache.org/~mloenko/snapshot_testing/script/r578410/index.html
> >>> [2] http://people.apache.org/~mloenko/snapshot_testing/script/r551077/index.html
> >>> [3] http://wiki.apache.org/harmony/milestones/M2
> >>> [4] http://mail-archives.apache.org/mod_mbox/harmony-dev/200706.mbox/%3c678b3f320706290508l554079dau6af1a82b17d62b54@mail.gmail.com%3e
> >>> [5] https://issues.apache.org/jira/browse/HARMONY-4843
> >>>
> >>> Thanks,
> >>> Stepan.
> >>>
> >>>
> >>>> Please feel free to pick up any issue for investigation. For example,
> >>>> 2 pack200 classlib test failed. Also there is a crash of
> >>>> org.apache.harmony.security.tests.java.security.cert.serialization.CertificateTest
> >>>> on Linux x86
> >>>>
> >>>> BTW, should we consider BTI's workspace (that we use for M3 testing)
> >>>> frozen too?
> >>>>
> >>>> [1] http://people.apache.org/~mloenko/snapshot_testing/script/r578410/index.html
> >>>>
> >>>> Thanks,
> >>>> Stepan.
> >
>
>
> --
> Gregory
Re: [general] M3 - code frozen
Posted by Alexey Petrenko <al...@gmail.com>.
2007/9/25, Gregory Shimansky <gs...@gmail.com>:
> Alexey Varlamov wrote:
> > Guys,
> >
> > Probably I'd articulate it more clearly :), but there is an issue
> > HARMONY-4844 "[build] Wrong hythr.lib copied to federated build" which
> > affects drlvm-tests run on snapshots. You might noticed strange number
> > of drlvm tests for Windows builds due to this. Not a big deal per se,
> > but it seems we already target new milestone candidate and it would be
> > better to apply this fix too to get correct results for next snapshot.
>
> +1 to commit. The patch looks totally harmless to me.
+1 for commit. Looks ok for me too.
SY, Alexey
> > 2007/9/25, Alexei Zakharov <al...@gmail.com>:
> >>> As I remember Sean took pack200 tests. And Alexei Zakharov took
> >>> security test crash.
> >> I've just said I'm able to reproduce failures :) However, I'll take a
> >> look. May be it can be fixed easily.
> >>
> >> Regards,
> >> Alexei
> >>
> >> 2007/9/25, Stepan Mishura <st...@gmail.com>:
> >>> On 9/24/07, Stepan Mishura <st...@gmail.com> wrote:
> >>>> On 9/22/07, Stepan Mishura wrote:
> >>>>> Hi,
> >>>>>
> >>>>> According to the plan - Sept. 22 is code freeze date for M3 so let's
> >>>>> follow policy:
> >>>>> "no more commits please without agreement from two committers on the dev list."
> >>>>>
> >>>>> Let's do more testing and analyze if there any critical/blocker issues
> >>>>> for consideration.
> >>>>> Please raise here issues that you think MUST be fixed for M3.
> >>>> Here is [1] the status of the last snapshot (r578410) that includes
> >>>> last classlib updates. Unfortunately, not everything is green there.
> >>>> I'm going to inspect all results to make sure that there are no
> >>>> failures caused by CC configuration issues.
> >>>>
> >>> I've compared testing status for the last snapshot r578410 [1] with M2 [2][3].
> >>>
> >>> We have the following short status for failed suites:
> >>>
> >>> Windows_x86:
> >>> * classlib: 2 tests from pack200 module fail on snapshot (but pass
> >>> on debug build)
> >>> * Eclipse unit tests 3.2: there is no tests report like for M3. The
> >>> pass rate was improved from 99.32%[3] to 99.7%[1]
> >>> * Eclipse unit tests 3.3 are new and the pass rate is 99.77%. I
> >>> think is acceptable
> >>> * EGA x48 hours scenario fails. According to [4] it passed on M2.
> >>> * Functional: need more analysis, currently I see that 2 tests were
> >>> enabled and new 15 regressions.
> >>> * Geronimo: 2 regressions
> >>> * JDK tools: 1 test failed. It might be intermediate failure - the
> >>> test failed due to timeout
> >>> * Reliability: 65 tests passed for M2 and 64 for M3. Investigation
> >>> is required.
> >>> * Stress: 190 tests passed for M2 and 189 for M3. Investigation is required.
> >>>
> >>> Linux_x86:
> >>> * classlib: 2 tests from pack200 (as for Windows), 1 luni tests
> >>> failed and 1 crash of security test
> >>> * Eclipse unit tests 3.2: 2 suites crashed so pass rate is 69.60%. I
> >>> assume this may be CC host configuration issue. Going to investigate.
> >>> * Eclipse unit tests 3.3 are new and the pass rate is 96.47%. I
> >>> think is acceptable
> >>> * EGA x48 hours scenario: the same as for Windows (scenario fails on M3)
> >>> * Functional: need more analysis, similar to Windows - some test are
> >>> passing now but there are new failures.
> >>> * Geronimo: 2 regressions (the same as for Windows)
> >>> * Reliability: need more analysis
> >>> * Stress: need more analysis
> >>>
> >>> As I remember Sean took pack200 tests. And Alexei Zakharov took
> >>> security test crash.
> >>> I'm going to sort things out with Eclipse unit tests 3.2 crash on
> >>> Linux. And to look info failed jdktools test.
> >>>
> >>> So volunteers are required for: EGAx48, Geronimo, functional,
> >>> reliability and stress suites.
> >>>
> >>> Also we have 2 JIRAs to be resolved for M3 under milstone unmblella[5]:
> >>> https://issues.apache.org/jira/browse/HARMONY-4844
> >>> https://issues.apache.org/jira/browse/HARMONY-4810
> >>>
> >>> [1] http://people.apache.org/~mloenko/snapshot_testing/script/r578410/index.html
> >>> [2] http://people.apache.org/~mloenko/snapshot_testing/script/r551077/index.html
> >>> [3] http://wiki.apache.org/harmony/milestones/M2
> >>> [4] http://mail-archives.apache.org/mod_mbox/harmony-dev/200706.mbox/%3c678b3f320706290508l554079dau6af1a82b17d62b54@mail.gmail.com%3e
> >>> [5] https://issues.apache.org/jira/browse/HARMONY-4843
> >>>
> >>> Thanks,
> >>> Stepan.
> >>>
> >>>
> >>>> Please feel free to pick up any issue for investigation. For example,
> >>>> 2 pack200 classlib test failed. Also there is a crash of
> >>>> org.apache.harmony.security.tests.java.security.cert.serialization.CertificateTest
> >>>> on Linux x86
> >>>>
> >>>> BTW, should we consider BTI's workspace (that we use for M3 testing)
> >>>> frozen too?
> >>>>
> >>>> [1] http://people.apache.org/~mloenko/snapshot_testing/script/r578410/index.html
> >>>>
> >>>> Thanks,
> >>>> Stepan.
> >
>
>
> --
> Gregory
>
>
Re: [general] M3 - code frozen
Posted by Gregory Shimansky <gs...@gmail.com>.
Alexey Varlamov wrote:
> Guys,
>
> Probably I'd articulate it more clearly :), but there is an issue
> HARMONY-4844 "[build] Wrong hythr.lib copied to federated build" which
> affects drlvm-tests run on snapshots. You might noticed strange number
> of drlvm tests for Windows builds due to this. Not a big deal per se,
> but it seems we already target new milestone candidate and it would be
> better to apply this fix too to get correct results for next snapshot.
+1 to commit. The patch looks totally harmless to me.
> 2007/9/25, Alexei Zakharov <al...@gmail.com>:
>>> As I remember Sean took pack200 tests. And Alexei Zakharov took
>>> security test crash.
>> I've just said I'm able to reproduce failures :) However, I'll take a
>> look. May be it can be fixed easily.
>>
>> Regards,
>> Alexei
>>
>> 2007/9/25, Stepan Mishura <st...@gmail.com>:
>>> On 9/24/07, Stepan Mishura <st...@gmail.com> wrote:
>>>> On 9/22/07, Stepan Mishura wrote:
>>>>> Hi,
>>>>>
>>>>> According to the plan - Sept. 22 is code freeze date for M3 so let's
>>>>> follow policy:
>>>>> "no more commits please without agreement from two committers on the dev list."
>>>>>
>>>>> Let's do more testing and analyze if there any critical/blocker issues
>>>>> for consideration.
>>>>> Please raise here issues that you think MUST be fixed for M3.
>>>> Here is [1] the status of the last snapshot (r578410) that includes
>>>> last classlib updates. Unfortunately, not everything is green there.
>>>> I'm going to inspect all results to make sure that there are no
>>>> failures caused by CC configuration issues.
>>>>
>>> I've compared testing status for the last snapshot r578410 [1] with M2 [2][3].
>>>
>>> We have the following short status for failed suites:
>>>
>>> Windows_x86:
>>> * classlib: 2 tests from pack200 module fail on snapshot (but pass
>>> on debug build)
>>> * Eclipse unit tests 3.2: there is no tests report like for M3. The
>>> pass rate was improved from 99.32%[3] to 99.7%[1]
>>> * Eclipse unit tests 3.3 are new and the pass rate is 99.77%. I
>>> think is acceptable
>>> * EGA x48 hours scenario fails. According to [4] it passed on M2.
>>> * Functional: need more analysis, currently I see that 2 tests were
>>> enabled and new 15 regressions.
>>> * Geronimo: 2 regressions
>>> * JDK tools: 1 test failed. It might be intermediate failure - the
>>> test failed due to timeout
>>> * Reliability: 65 tests passed for M2 and 64 for M3. Investigation
>>> is required.
>>> * Stress: 190 tests passed for M2 and 189 for M3. Investigation is required.
>>>
>>> Linux_x86:
>>> * classlib: 2 tests from pack200 (as for Windows), 1 luni tests
>>> failed and 1 crash of security test
>>> * Eclipse unit tests 3.2: 2 suites crashed so pass rate is 69.60%. I
>>> assume this may be CC host configuration issue. Going to investigate.
>>> * Eclipse unit tests 3.3 are new and the pass rate is 96.47%. I
>>> think is acceptable
>>> * EGA x48 hours scenario: the same as for Windows (scenario fails on M3)
>>> * Functional: need more analysis, similar to Windows - some test are
>>> passing now but there are new failures.
>>> * Geronimo: 2 regressions (the same as for Windows)
>>> * Reliability: need more analysis
>>> * Stress: need more analysis
>>>
>>> As I remember Sean took pack200 tests. And Alexei Zakharov took
>>> security test crash.
>>> I'm going to sort things out with Eclipse unit tests 3.2 crash on
>>> Linux. And to look info failed jdktools test.
>>>
>>> So volunteers are required for: EGAx48, Geronimo, functional,
>>> reliability and stress suites.
>>>
>>> Also we have 2 JIRAs to be resolved for M3 under milstone unmblella[5]:
>>> https://issues.apache.org/jira/browse/HARMONY-4844
>>> https://issues.apache.org/jira/browse/HARMONY-4810
>>>
>>> [1] http://people.apache.org/~mloenko/snapshot_testing/script/r578410/index.html
>>> [2] http://people.apache.org/~mloenko/snapshot_testing/script/r551077/index.html
>>> [3] http://wiki.apache.org/harmony/milestones/M2
>>> [4] http://mail-archives.apache.org/mod_mbox/harmony-dev/200706.mbox/%3c678b3f320706290508l554079dau6af1a82b17d62b54@mail.gmail.com%3e
>>> [5] https://issues.apache.org/jira/browse/HARMONY-4843
>>>
>>> Thanks,
>>> Stepan.
>>>
>>>
>>>> Please feel free to pick up any issue for investigation. For example,
>>>> 2 pack200 classlib test failed. Also there is a crash of
>>>> org.apache.harmony.security.tests.java.security.cert.serialization.CertificateTest
>>>> on Linux x86
>>>>
>>>> BTW, should we consider BTI's workspace (that we use for M3 testing)
>>>> frozen too?
>>>>
>>>> [1] http://people.apache.org/~mloenko/snapshot_testing/script/r578410/index.html
>>>>
>>>> Thanks,
>>>> Stepan.
>
--
Gregory
Re: [general] M3 - code frozen
Posted by Alexey Varlamov <al...@gmail.com>.
Guys,
Probably I'd articulate it more clearly :), but there is an issue
HARMONY-4844 "[build] Wrong hythr.lib copied to federated build" which
affects drlvm-tests run on snapshots. You might noticed strange number
of drlvm tests for Windows builds due to this. Not a big deal per se,
but it seems we already target new milestone candidate and it would be
better to apply this fix too to get correct results for next snapshot.
--
Alexey
2007/9/25, Alexei Zakharov <al...@gmail.com>:
> > As I remember Sean took pack200 tests. And Alexei Zakharov took
> > security test crash.
>
> I've just said I'm able to reproduce failures :) However, I'll take a
> look. May be it can be fixed easily.
>
> Regards,
> Alexei
>
> 2007/9/25, Stepan Mishura <st...@gmail.com>:
> > On 9/24/07, Stepan Mishura <st...@gmail.com> wrote:
> > > On 9/22/07, Stepan Mishura wrote:
> > > > Hi,
> > > >
> > > > According to the plan - Sept. 22 is code freeze date for M3 so let's
> > > > follow policy:
> > > > "no more commits please without agreement from two committers on the dev list."
> > > >
> > > > Let's do more testing and analyze if there any critical/blocker issues
> > > > for consideration.
> > > > Please raise here issues that you think MUST be fixed for M3.
> > >
> > > Here is [1] the status of the last snapshot (r578410) that includes
> > > last classlib updates. Unfortunately, not everything is green there.
> > > I'm going to inspect all results to make sure that there are no
> > > failures caused by CC configuration issues.
> > >
> >
> > I've compared testing status for the last snapshot r578410 [1] with M2 [2][3].
> >
> > We have the following short status for failed suites:
> >
> > Windows_x86:
> > * classlib: 2 tests from pack200 module fail on snapshot (but pass
> > on debug build)
> > * Eclipse unit tests 3.2: there is no tests report like for M3. The
> > pass rate was improved from 99.32%[3] to 99.7%[1]
> > * Eclipse unit tests 3.3 are new and the pass rate is 99.77%. I
> > think is acceptable
> > * EGA x48 hours scenario fails. According to [4] it passed on M2.
> > * Functional: need more analysis, currently I see that 2 tests were
> > enabled and new 15 regressions.
> > * Geronimo: 2 regressions
> > * JDK tools: 1 test failed. It might be intermediate failure - the
> > test failed due to timeout
> > * Reliability: 65 tests passed for M2 and 64 for M3. Investigation
> > is required.
> > * Stress: 190 tests passed for M2 and 189 for M3. Investigation is required.
> >
> > Linux_x86:
> > * classlib: 2 tests from pack200 (as for Windows), 1 luni tests
> > failed and 1 crash of security test
> > * Eclipse unit tests 3.2: 2 suites crashed so pass rate is 69.60%. I
> > assume this may be CC host configuration issue. Going to investigate.
> > * Eclipse unit tests 3.3 are new and the pass rate is 96.47%. I
> > think is acceptable
> > * EGA x48 hours scenario: the same as for Windows (scenario fails on M3)
> > * Functional: need more analysis, similar to Windows - some test are
> > passing now but there are new failures.
> > * Geronimo: 2 regressions (the same as for Windows)
> > * Reliability: need more analysis
> > * Stress: need more analysis
> >
> > As I remember Sean took pack200 tests. And Alexei Zakharov took
> > security test crash.
> > I'm going to sort things out with Eclipse unit tests 3.2 crash on
> > Linux. And to look info failed jdktools test.
> >
> > So volunteers are required for: EGAx48, Geronimo, functional,
> > reliability and stress suites.
> >
> > Also we have 2 JIRAs to be resolved for M3 under milstone unmblella[5]:
> > https://issues.apache.org/jira/browse/HARMONY-4844
> > https://issues.apache.org/jira/browse/HARMONY-4810
> >
> > [1] http://people.apache.org/~mloenko/snapshot_testing/script/r578410/index.html
> > [2] http://people.apache.org/~mloenko/snapshot_testing/script/r551077/index.html
> > [3] http://wiki.apache.org/harmony/milestones/M2
> > [4] http://mail-archives.apache.org/mod_mbox/harmony-dev/200706.mbox/%3c678b3f320706290508l554079dau6af1a82b17d62b54@mail.gmail.com%3e
> > [5] https://issues.apache.org/jira/browse/HARMONY-4843
> >
> > Thanks,
> > Stepan.
> >
> >
> > > Please feel free to pick up any issue for investigation. For example,
> > > 2 pack200 classlib test failed. Also there is a crash of
> > > org.apache.harmony.security.tests.java.security.cert.serialization.CertificateTest
> > > on Linux x86
> > >
> > > BTW, should we consider BTI's workspace (that we use for M3 testing)
> > > frozen too?
> > >
> > > [1] http://people.apache.org/~mloenko/snapshot_testing/script/r578410/index.html
> > >
> > > Thanks,
> > > Stepan.
>
Re: [general] M3 - code frozen
Posted by Alexei Zakharov <al...@gmail.com>.
> As I remember Sean took pack200 tests. And Alexei Zakharov took
> security test crash.
I've just said I'm able to reproduce failures :) However, I'll take a
look. May be it can be fixed easily.
Regards,
Alexei
2007/9/25, Stepan Mishura <st...@gmail.com>:
> On 9/24/07, Stepan Mishura <st...@gmail.com> wrote:
> > On 9/22/07, Stepan Mishura wrote:
> > > Hi,
> > >
> > > According to the plan - Sept. 22 is code freeze date for M3 so let's
> > > follow policy:
> > > "no more commits please without agreement from two committers on the dev list."
> > >
> > > Let's do more testing and analyze if there any critical/blocker issues
> > > for consideration.
> > > Please raise here issues that you think MUST be fixed for M3.
> >
> > Here is [1] the status of the last snapshot (r578410) that includes
> > last classlib updates. Unfortunately, not everything is green there.
> > I'm going to inspect all results to make sure that there are no
> > failures caused by CC configuration issues.
> >
>
> I've compared testing status for the last snapshot r578410 [1] with M2 [2][3].
>
> We have the following short status for failed suites:
>
> Windows_x86:
> * classlib: 2 tests from pack200 module fail on snapshot (but pass
> on debug build)
> * Eclipse unit tests 3.2: there is no tests report like for M3. The
> pass rate was improved from 99.32%[3] to 99.7%[1]
> * Eclipse unit tests 3.3 are new and the pass rate is 99.77%. I
> think is acceptable
> * EGA x48 hours scenario fails. According to [4] it passed on M2.
> * Functional: need more analysis, currently I see that 2 tests were
> enabled and new 15 regressions.
> * Geronimo: 2 regressions
> * JDK tools: 1 test failed. It might be intermediate failure - the
> test failed due to timeout
> * Reliability: 65 tests passed for M2 and 64 for M3. Investigation
> is required.
> * Stress: 190 tests passed for M2 and 189 for M3. Investigation is required.
>
> Linux_x86:
> * classlib: 2 tests from pack200 (as for Windows), 1 luni tests
> failed and 1 crash of security test
> * Eclipse unit tests 3.2: 2 suites crashed so pass rate is 69.60%. I
> assume this may be CC host configuration issue. Going to investigate.
> * Eclipse unit tests 3.3 are new and the pass rate is 96.47%. I
> think is acceptable
> * EGA x48 hours scenario: the same as for Windows (scenario fails on M3)
> * Functional: need more analysis, similar to Windows - some test are
> passing now but there are new failures.
> * Geronimo: 2 regressions (the same as for Windows)
> * Reliability: need more analysis
> * Stress: need more analysis
>
> As I remember Sean took pack200 tests. And Alexei Zakharov took
> security test crash.
> I'm going to sort things out with Eclipse unit tests 3.2 crash on
> Linux. And to look info failed jdktools test.
>
> So volunteers are required for: EGAx48, Geronimo, functional,
> reliability and stress suites.
>
> Also we have 2 JIRAs to be resolved for M3 under milstone unmblella[5]:
> https://issues.apache.org/jira/browse/HARMONY-4844
> https://issues.apache.org/jira/browse/HARMONY-4810
>
> [1] http://people.apache.org/~mloenko/snapshot_testing/script/r578410/index.html
> [2] http://people.apache.org/~mloenko/snapshot_testing/script/r551077/index.html
> [3] http://wiki.apache.org/harmony/milestones/M2
> [4] http://mail-archives.apache.org/mod_mbox/harmony-dev/200706.mbox/%3c678b3f320706290508l554079dau6af1a82b17d62b54@mail.gmail.com%3e
> [5] https://issues.apache.org/jira/browse/HARMONY-4843
>
> Thanks,
> Stepan.
>
>
> > Please feel free to pick up any issue for investigation. For example,
> > 2 pack200 classlib test failed. Also there is a crash of
> > org.apache.harmony.security.tests.java.security.cert.serialization.CertificateTest
> > on Linux x86
> >
> > BTW, should we consider BTI's workspace (that we use for M3 testing)
> > frozen too?
> >
> > [1] http://people.apache.org/~mloenko/snapshot_testing/script/r578410/index.html
> >
> > Thanks,
> > Stepan.
Re: [general] M3 - code frozen
Posted by Rana Dasgupta <rd...@gmail.com>.
On 9/26/07, Xiao-Feng Li <xi...@gmail.com> wrote:
> On 9/26/07, Stepan Mishura <st...@gmail.com> wrote:
> > On 9/25/07, Xiao-Feng Li <xi...@gmail.com> wrote:
> > > Hi, Stepan and folks,
> > >
> > > After looking at the testing results in the page given below, I feel
> > > the status of the revisionon X86-64 is quite "good". It is not
> > > perfect, but better than I expected. I'd suggest we consider to
> > > include X86-64 into our M3 build this time. It's an acceptable
> > > starting baseline, and we can improve it and will see better situation
> > > with M4, M5, etc.
> > >
> > > How do you guys think?
> > >
> >
> > Yes, I agree that it looks quite good. I think it is possible to
> > release it but I think we should be aware about its status (i.e.
> > quality) - it is less tested and results are worse then for x86. If we
> > want to release it then IMHO that all testing results available should
> > be reviewed and summary of existing problems should be created. If
> > there are no blocking issues for x86_64 release then I think it can be
> > released. (Why not?)
> > I assume that most of the folks are looking into x86 failres first..
> > So if you volunteer to review testing results for x86_64 that would be
> > great!
>
> Stepan, my suggestion was to take current status as the starting
> baseline for X86-64. We don't need spend additional time for any
> failures specific to X86-64 this time. In my last email, I mentioned
> that I had checked the "must-pass" tests and thought they are ok. I
> never engaged in a releasing procedure, so I don't know what are
> considered to be "blocking issues", and what kind of summary we need.
> Do you mean the list of failures?
>
>
I think that it is probably OK to include X86-64 in M3 with a simple
disclaimer in the release notes about it not being error free and lack
of heap support > 4GB. Stepan, is there a problem with doing this,
given that we are adding a new platform?
Re: [general] M3 - code frozen
Posted by Xiao-Feng Li <xi...@gmail.com>.
On 9/26/07, Stepan Mishura <st...@gmail.com> wrote:
> On 9/25/07, Xiao-Feng Li <xi...@gmail.com> wrote:
> > Hi, Stepan and folks,
> >
> > After looking at the testing results in the page given below, I feel
> > the status of the revisionon X86-64 is quite "good". It is not
> > perfect, but better than I expected. I'd suggest we consider to
> > include X86-64 into our M3 build this time. It's an acceptable
> > starting baseline, and we can improve it and will see better situation
> > with M4, M5, etc.
> >
> > How do you guys think?
> >
>
> Yes, I agree that it looks quite good. I think it is possible to
> release it but I think we should be aware about its status (i.e.
> quality) - it is less tested and results are worse then for x86. If we
> want to release it then IMHO that all testing results available should
> be reviewed and summary of existing problems should be created. If
> there are no blocking issues for x86_64 release then I think it can be
> released. (Why not?)
> I assume that most of the folks are looking into x86 failres first..
> So if you volunteer to review testing results for x86_64 that would be
> great!
Stepan, my suggestion was to take current status as the starting
baseline for X86-64. We don't need spend additional time for any
failures specific to X86-64 this time. In my last email, I mentioned
that I had checked the "must-pass" tests and thought they are ok. I
never engaged in a releasing procedure, so I don't know what are
considered to be "blocking issues", and what kind of summary we need.
Do you mean the list of failures?
Thanks,
xiaofeng
> Thanks,
> Stepan.
>
> > Btw, The caveat for the X86-64 build is, they can only support up to
> > 4GB heap size currently. Hopefully this will be changed in M4 or M5.
> >
> > PS, I checked the results in Linux64 for those "must pass" tests, such
> > as Dacapo and "DRLVM tests". I found the two failures in "DRLVM tests"
> > are "failures" rather than "errors", which I guess are actually
> > time-out. The failure in Dacapo is with Chart, showing a null pointer
> > in AWT. I personally think we can leave it as is for M3.
> >
> > Thanks,
> > xiaofeng
> >
> >
> > On 9/25/07, Stepan Mishura <st...@gmail.com> wrote:
> > > On 9/24/07, Stepan Mishura <st...@gmail.com> wrote:
> > > > On 9/22/07, Stepan Mishura wrote:
> > > > > Hi,
> > > > >
> > > > > According to the plan - Sept. 22 is code freeze date for M3 so let's
> > > > > follow policy:
> > > > > "no more commits please without agreement from two committers on the dev list."
> > > > >
> > > > > Let's do more testing and analyze if there any critical/blocker issues
> > > > > for consideration.
> > > > > Please raise here issues that you think MUST be fixed for M3.
> > > >
> > > > Here is [1] the status of the last snapshot (r578410) that includes
> > > > last classlib updates. Unfortunately, not everything is green there.
> > > > I'm going to inspect all results to make sure that there are no
> > > > failures caused by CC configuration issues.
> > > >
> > >
> > > I've compared testing status for the last snapshot r578410 [1] with M2 [2][3].
> > >
> > > We have the following short status for failed suites:
> > >
> > > Windows_x86:
> > > * classlib: 2 tests from pack200 module fail on snapshot (but pass
> > > on debug build)
> > > * Eclipse unit tests 3.2: there is no tests report like for M3. The
> > > pass rate was improved from 99.32%[3] to 99.7%[1]
> > > * Eclipse unit tests 3.3 are new and the pass rate is 99.77%. I
> > > think is acceptable
> > > * EGA x48 hours scenario fails. According to [4] it passed on M2.
> > > * Functional: need more analysis, currently I see that 2 tests were
> > > enabled and new 15 regressions.
> > > * Geronimo: 2 regressions
> > > * JDK tools: 1 test failed. It might be intermediate failure - the
> > > test failed due to timeout
> > > * Reliability: 65 tests passed for M2 and 64 for M3. Investigation
> > > is required.
> > > * Stress: 190 tests passed for M2 and 189 for M3. Investigation is required.
> > >
> > > Linux_x86:
> > > * classlib: 2 tests from pack200 (as for Windows), 1 luni tests
> > > failed and 1 crash of security test
> > > * Eclipse unit tests 3.2: 2 suites crashed so pass rate is 69.60%. I
> > > assume this may be CC host configuration issue. Going to investigate.
> > > * Eclipse unit tests 3.3 are new and the pass rate is 96.47%. I
> > > think is acceptable
> > > * EGA x48 hours scenario: the same as for Windows (scenario fails on M3)
> > > * Functional: need more analysis, similar to Windows - some test are
> > > passing now but there are new failures.
> > > * Geronimo: 2 regressions (the same as for Windows)
> > > * Reliability: need more analysis
> > > * Stress: need more analysis
> > >
> > > As I remember Sean took pack200 tests. And Alexei Zakharov took
> > > security test crash.
> > > I'm going to sort things out with Eclipse unit tests 3.2 crash on
> > > Linux. And to look info failed jdktools test.
> > >
> > > So volunteers are required for: EGAx48, Geronimo, functional,
> > > reliability and stress suites.
> > >
> > > Also we have 2 JIRAs to be resolved for M3 under milstone unmblella[5]:
> > > https://issues.apache.org/jira/browse/HARMONY-4844
> > > https://issues.apache.org/jira/browse/HARMONY-4810
> > >
> > > [1] http://people.apache.org/~mloenko/snapshot_testing/script/r578410/index.html
> > > [2] http://people.apache.org/~mloenko/snapshot_testing/script/r551077/index.html
> > > [3] http://wiki.apache.org/harmony/milestones/M2
> > > [4] http://mail-archives.apache.org/mod_mbox/harmony-dev/200706.mbox/%3c678b3f320706290508l554079dau6af1a82b17d62b54@mail.gmail.com%3e
> > > [5] https://issues.apache.org/jira/browse/HARMONY-4843
> > >
> > > Thanks,
> > > Stepan.
> > >
> > >
> > > > Please feel free to pick up any issue for investigation. For example,
> > > > 2 pack200 classlib test failed. Also there is a crash of
> > > > org.apache.harmony.security.tests.java.security.cert.serialization.CertificateTest
> > > > on Linux x86
> > > >
> > > > BTW, should we consider BTI's workspace (that we use for M3 testing)
> > > > frozen too?
> > > >
> > > > [1] http://people.apache.org/~mloenko/snapshot_testing/script/r578410/index.html
> > > >
> > > > Thanks,
> > > > Stepan.
> > >
> >
> >
> > --
> > http://xiao-feng.blogspot.com
> >
>
--
http://xiao-feng.blogspot.com
Re: [general] M3 - code frozen
Posted by Stepan Mishura <st...@gmail.com>.
On 9/25/07, Xiao-Feng Li <xi...@gmail.com> wrote:
> Hi, Stepan and folks,
>
> After looking at the testing results in the page given below, I feel
> the status of the revisionon X86-64 is quite "good". It is not
> perfect, but better than I expected. I'd suggest we consider to
> include X86-64 into our M3 build this time. It's an acceptable
> starting baseline, and we can improve it and will see better situation
> with M4, M5, etc.
>
> How do you guys think?
>
Yes, I agree that it looks quite good. I think it is possible to
release it but I think we should be aware about its status (i.e.
quality) - it is less tested and results are worse then for x86. If we
want to release it then IMHO that all testing results available should
be reviewed and summary of existing problems should be created. If
there are no blocking issues for x86_64 release then I think it can be
released. (Why not?)
I assume that most of the folks are looking into x86 failres first..
So if you volunteer to review testing results for x86_64 that would be
great!
Thanks,
Stepan.
> Btw, The caveat for the X86-64 build is, they can only support up to
> 4GB heap size currently. Hopefully this will be changed in M4 or M5.
>
> PS, I checked the results in Linux64 for those "must pass" tests, such
> as Dacapo and "DRLVM tests". I found the two failures in "DRLVM tests"
> are "failures" rather than "errors", which I guess are actually
> time-out. The failure in Dacapo is with Chart, showing a null pointer
> in AWT. I personally think we can leave it as is for M3.
>
> Thanks,
> xiaofeng
>
>
> On 9/25/07, Stepan Mishura <st...@gmail.com> wrote:
> > On 9/24/07, Stepan Mishura <st...@gmail.com> wrote:
> > > On 9/22/07, Stepan Mishura wrote:
> > > > Hi,
> > > >
> > > > According to the plan - Sept. 22 is code freeze date for M3 so let's
> > > > follow policy:
> > > > "no more commits please without agreement from two committers on the dev list."
> > > >
> > > > Let's do more testing and analyze if there any critical/blocker issues
> > > > for consideration.
> > > > Please raise here issues that you think MUST be fixed for M3.
> > >
> > > Here is [1] the status of the last snapshot (r578410) that includes
> > > last classlib updates. Unfortunately, not everything is green there.
> > > I'm going to inspect all results to make sure that there are no
> > > failures caused by CC configuration issues.
> > >
> >
> > I've compared testing status for the last snapshot r578410 [1] with M2 [2][3].
> >
> > We have the following short status for failed suites:
> >
> > Windows_x86:
> > * classlib: 2 tests from pack200 module fail on snapshot (but pass
> > on debug build)
> > * Eclipse unit tests 3.2: there is no tests report like for M3. The
> > pass rate was improved from 99.32%[3] to 99.7%[1]
> > * Eclipse unit tests 3.3 are new and the pass rate is 99.77%. I
> > think is acceptable
> > * EGA x48 hours scenario fails. According to [4] it passed on M2.
> > * Functional: need more analysis, currently I see that 2 tests were
> > enabled and new 15 regressions.
> > * Geronimo: 2 regressions
> > * JDK tools: 1 test failed. It might be intermediate failure - the
> > test failed due to timeout
> > * Reliability: 65 tests passed for M2 and 64 for M3. Investigation
> > is required.
> > * Stress: 190 tests passed for M2 and 189 for M3. Investigation is required.
> >
> > Linux_x86:
> > * classlib: 2 tests from pack200 (as for Windows), 1 luni tests
> > failed and 1 crash of security test
> > * Eclipse unit tests 3.2: 2 suites crashed so pass rate is 69.60%. I
> > assume this may be CC host configuration issue. Going to investigate.
> > * Eclipse unit tests 3.3 are new and the pass rate is 96.47%. I
> > think is acceptable
> > * EGA x48 hours scenario: the same as for Windows (scenario fails on M3)
> > * Functional: need more analysis, similar to Windows - some test are
> > passing now but there are new failures.
> > * Geronimo: 2 regressions (the same as for Windows)
> > * Reliability: need more analysis
> > * Stress: need more analysis
> >
> > As I remember Sean took pack200 tests. And Alexei Zakharov took
> > security test crash.
> > I'm going to sort things out with Eclipse unit tests 3.2 crash on
> > Linux. And to look info failed jdktools test.
> >
> > So volunteers are required for: EGAx48, Geronimo, functional,
> > reliability and stress suites.
> >
> > Also we have 2 JIRAs to be resolved for M3 under milstone unmblella[5]:
> > https://issues.apache.org/jira/browse/HARMONY-4844
> > https://issues.apache.org/jira/browse/HARMONY-4810
> >
> > [1] http://people.apache.org/~mloenko/snapshot_testing/script/r578410/index.html
> > [2] http://people.apache.org/~mloenko/snapshot_testing/script/r551077/index.html
> > [3] http://wiki.apache.org/harmony/milestones/M2
> > [4] http://mail-archives.apache.org/mod_mbox/harmony-dev/200706.mbox/%3c678b3f320706290508l554079dau6af1a82b17d62b54@mail.gmail.com%3e
> > [5] https://issues.apache.org/jira/browse/HARMONY-4843
> >
> > Thanks,
> > Stepan.
> >
> >
> > > Please feel free to pick up any issue for investigation. For example,
> > > 2 pack200 classlib test failed. Also there is a crash of
> > > org.apache.harmony.security.tests.java.security.cert.serialization.CertificateTest
> > > on Linux x86
> > >
> > > BTW, should we consider BTI's workspace (that we use for M3 testing)
> > > frozen too?
> > >
> > > [1] http://people.apache.org/~mloenko/snapshot_testing/script/r578410/index.html
> > >
> > > Thanks,
> > > Stepan.
> >
>
>
> --
> http://xiao-feng.blogspot.com
>
Re: [general] x86-64 builds (was: Re: [general] M3 - code frozen)
Posted by Rana Dasgupta <rd...@gmail.com>.
On 9/27/07, Tim Ellison <t....@gmail.com> wrote:
> Rana Dasgupta wrote:
> > If we were to add
> > x86-64 to M3, it would be under disclaimer only( it's a late decision,
> > and it looks relatively good ), we can't claim that that it has the
> > stability of the 32 bit distributions.
>
> Our milestones are taken to be stable builds of our current
> functionality; if the stability has not yet been achieved then I think
> it is fine to keep publishing x86-64 as "snapshot" builds. Making that
> platform a 'milestone build with disclaimers' just makes the meaning of
> milestones confusing IMHO.
>
> If we are close to achieving x86-64 stability then having a short cycle
> to include it in an M4 might make sense.
>
Makes sense, it does create some ambiguity between milestone and
snapshot builds. We can try in M4.
Thanks,
Rana
> Regards,
> Tim
>
>
>
>
Re: [general] x86-64 builds (was: Re: [general] M3 - code frozen)
Posted by Xiao-Feng Li <xi...@gmail.com>.
On 9/27/07, Stepan Mishura <st...@gmail.com> wrote:
> On 9/27/07, Tim Ellison <t....@gmail.com> wrote:
> > Rana Dasgupta wrote:
> > > If we were to add
> > > x86-64 to M3, it would be under disclaimer only( it's a late decision,
> > > and it looks relatively good ), we can't claim that that it has the
> > > stability of the 32 bit distributions.
> >
>
> Yes, the results looks good but I feel that x86-64 platform is far
> from being stable. For example, from my experience the most unstable
> platform is Linux 64bits. I very often have to restart CC or even
> reboot a host to make CC alive.
>
> We may use M3 testing status for x86-64 as baseline for measuring its
> progress and including it to the next release.
> Thanks,
> Stepan.
We should define some stability criteria for the release, so that we
know whether a revision meets or not. So far I don't know what are
"blocking issues" for a stable build.
Thanks,
xiaofeng
>
> > Our milestones are taken to be stable builds of our current
> > functionality; if the stability has not yet been achieved then I think
> > it is fine to keep publishing x86-64 as "snapshot" builds. Making that
> > platform a 'milestone build with disclaimers' just makes the meaning of
> > milestones confusing IMHO.
> >
> > If we are close to achieving x86-64 stability then having a short cycle
> > to include it in an M4 might make sense.
> >
> > Regards,
> > Tim
>
--
http://xiao-feng.blogspot.com
Re: [general] x86-64 builds (was: Re: [general] M3 - code frozen)
Posted by Stepan Mishura <st...@gmail.com>.
On 9/27/07, Tim Ellison <t....@gmail.com> wrote:
> Rana Dasgupta wrote:
> > If we were to add
> > x86-64 to M3, it would be under disclaimer only( it's a late decision,
> > and it looks relatively good ), we can't claim that that it has the
> > stability of the 32 bit distributions.
>
Yes, the results looks good but I feel that x86-64 platform is far
from being stable. For example, from my experience the most unstable
platform is Linux 64bits. I very often have to restart CC or even
reboot a host to make CC alive.
We may use M3 testing status for x86-64 as baseline for measuring its
progress and including it to the next release.
Thanks,
Stepan.
> Our milestones are taken to be stable builds of our current
> functionality; if the stability has not yet been achieved then I think
> it is fine to keep publishing x86-64 as "snapshot" builds. Making that
> platform a 'milestone build with disclaimers' just makes the meaning of
> milestones confusing IMHO.
>
> If we are close to achieving x86-64 stability then having a short cycle
> to include it in an M4 might make sense.
>
> Regards,
> Tim
[general] x86-64 builds (was: Re: [general] M3 - code frozen)
Posted by Tim Ellison <t....@gmail.com>.
Rana Dasgupta wrote:
> If we were to add
> x86-64 to M3, it would be under disclaimer only( it's a late decision,
> and it looks relatively good ), we can't claim that that it has the
> stability of the 32 bit distributions.
Our milestones are taken to be stable builds of our current
functionality; if the stability has not yet been achieved then I think
it is fine to keep publishing x86-64 as "snapshot" builds. Making that
platform a 'milestone build with disclaimers' just makes the meaning of
milestones confusing IMHO.
If we are close to achieving x86-64 stability then having a short cycle
to include it in an M4 might make sense.
Regards,
Tim
Re: [general] M3 - code frozen
Posted by Rana Dasgupta <rd...@gmail.com>.
Unfortunately I don't have access to a 64 bit Linux at this moment. It
looks like gc completed a major collection successfully and there is
some failure post collection when it is trying to tune heap sizes
based on performance of last collection. Is this a blocking failure? I
don't remember how have we defined blocking failure. If we were to add
x86-64 to M3, it would be under disclaimer only( it's a late decision,
and it looks relatively good ), we can't claim that that it has the
stability of the 32 bit distributions.
On 9/26/07, Alexey Varlamov <al...@gmail.com> wrote:
> 2007/9/26, Xiao-Feng Li <xi...@gmail.com>:
> > On 9/26/07, Alexey Varlamov <al...@gmail.com> wrote:
> > > Xiao-Feng,
> > >
> > > Idea is really interesting and it's a pity it came too late in M3. I
> > > believe we're not going to prolong M3 closing date after this weekend
> > > but OTOH suspect we have no spare hands to sort out critical x86-64
> > > issues for remained days. I'd love someone rebut my doubts.
> > > BTW, here is one of issues: self-hosting crashed on latest Linux-64 snapshot [1]
> > >
> > > [java] SIGSEGV in VM code.
> > > [java] Stack trace:
> > > [java] 0: gc_gen_adapt(GC_Gen*, long long) (??:-1)
> > > [java] 1: pthread_mutex_unlock (??:-1)
> > > [java] 2: apr_thread_mutex_unlock (locks/unix/thread_mutex.c:129)
> > > [java] 3: apr_atomic_casptr (atomic/unix/apr_atomic.c:376)
> > > [java] 4: log4cxx::helpers::ObjectImpl::releaseRef() const (??:-1)
> > > [java] 5: gc_gen_reclaim_heap(GC_Gen*, long long) (??:-1)
> > > [java] 6: pthread_mutex_unlock (??:-1)
> > > [java] 7: apr_thread_mutex_unlock (locks/unix/thread_mutex.c:129)
> > > [java] 8: ?? (??:-1)
> > > [java] 9: gc_reclaim_heap(GC*, unsigned int) (??:-1)
> > > [java] 10: pthread_mutex_lock (??:-1)
> > > [java] 11: hymutex_lock (??:-1)
> > > [java] 12: fspace_alloc(unsigned int, Allocator*) (??:-1)
> > > [java] 13: nos_alloc(unsigned int, Allocator*) (??:-1)
> > > [java] 14: gc_alloc (??:-1)
> > > [java] 15: vm_new_vector(Class*, int) (??:-1)
> > > [java] 16: vm_multianewarray_recursive(Class*, int*, unsigned int) (??:-1)
> > > [java] 17: vm_rt_multianewarray_recursive(Class*, int*, unsigned
> > > int) (??:-1)
> > >
> > > [1] http://people.apache.org/~smishura/r579330/Linux_x86_64/hdk_by_hdk/
> >
> > Alexey, I don't understand what you mean. Do you mean we should fix
> > the failure immediately before we can consider a Linux64 M3 build?
>
> Xiao-Feng,
> Fix is always the best ;), but we need at least understand how
> critical the failure is.
> I assume we base milestone on achieving certain conscious level of
> stability; then we need to evaluate known issues and decide if we
> tolerate them for the moment. E.g. if some intermittent failure
> appears quite often (and on reasonable workloads), do we want to call
> this build stable?
>
> --
> Thanks,
> Alexey
>
> >
> > Thanks,
> > xiaofeng
> >
> > >
> > > 2007/9/25, Xiao-Feng Li <xi...@gmail.com>:
> > > > Hi, Stepan and folks,
> > > >
> > > > After looking at the testing results in the page given below, I feel
> > > > the status of the revisionon X86-64 is quite "good". It is not
> > > > perfect, but better than I expected. I'd suggest we consider to
> > > > include X86-64 into our M3 build this time. It's an acceptable
> > > > starting baseline, and we can improve it and will see better situation
> > > > with M4, M5, etc.
> > > >
> > > > How do you guys think?
> > > >
> > > > Btw, The caveat for the X86-64 build is, they can only support up to
> > > > 4GB heap size currently. Hopefully this will be changed in M4 or M5.
> > > >
> > > > PS, I checked the results in Linux64 for those "must pass" tests, such
> > > > as Dacapo and "DRLVM tests". I found the two failures in "DRLVM tests"
> > > > are "failures" rather than "errors", which I guess are actually
> > > > time-out. The failure in Dacapo is with Chart, showing a null pointer
> > > > in AWT. I personally think we can leave it as is for M3.
> > > >
> > > > Thanks,
> > > > xiaofeng
> > > >
> > > >
> > > > On 9/25/07, Stepan Mishura <st...@gmail.com> wrote:
> > > > > On 9/24/07, Stepan Mishura <st...@gmail.com> wrote:
> > > > > > On 9/22/07, Stepan Mishura wrote:
> > > > > > > Hi,
> > > > > > >
> > > > > > > According to the plan - Sept. 22 is code freeze date for M3 so let's
> > > > > > > follow policy:
> > > > > > > "no more commits please without agreement from two committers on the dev list."
> > > > > > >
> > > > > > > Let's do more testing and analyze if there any critical/blocker issues
> > > > > > > for consideration.
> > > > > > > Please raise here issues that you think MUST be fixed for M3.
> > > > > >
> > > > > > Here is [1] the status of the last snapshot (r578410) that includes
> > > > > > last classlib updates. Unfortunately, not everything is green there.
> > > > > > I'm going to inspect all results to make sure that there are no
> > > > > > failures caused by CC configuration issues.
> > > > > >
> > > > >
> > > > > I've compared testing status for the last snapshot r578410 [1] with M2 [2][3].
> > > > >
> > > > > We have the following short status for failed suites:
> > > > >
> > > > > Windows_x86:
> > > > > * classlib: 2 tests from pack200 module fail on snapshot (but pass
> > > > > on debug build)
> > > > > * Eclipse unit tests 3.2: there is no tests report like for M3. The
> > > > > pass rate was improved from 99.32%[3] to 99.7%[1]
> > > > > * Eclipse unit tests 3.3 are new and the pass rate is 99.77%. I
> > > > > think is acceptable
> > > > > * EGA x48 hours scenario fails. According to [4] it passed on M2.
> > > > > * Functional: need more analysis, currently I see that 2 tests were
> > > > > enabled and new 15 regressions.
> > > > > * Geronimo: 2 regressions
> > > > > * JDK tools: 1 test failed. It might be intermediate failure - the
> > > > > test failed due to timeout
> > > > > * Reliability: 65 tests passed for M2 and 64 for M3. Investigation
> > > > > is required.
> > > > > * Stress: 190 tests passed for M2 and 189 for M3. Investigation is required.
> > > > >
> > > > > Linux_x86:
> > > > > * classlib: 2 tests from pack200 (as for Windows), 1 luni tests
> > > > > failed and 1 crash of security test
> > > > > * Eclipse unit tests 3.2: 2 suites crashed so pass rate is 69.60%. I
> > > > > assume this may be CC host configuration issue. Going to investigate.
> > > > > * Eclipse unit tests 3.3 are new and the pass rate is 96.47%. I
> > > > > think is acceptable
> > > > > * EGA x48 hours scenario: the same as for Windows (scenario fails on M3)
> > > > > * Functional: need more analysis, similar to Windows - some test are
> > > > > passing now but there are new failures.
> > > > > * Geronimo: 2 regressions (the same as for Windows)
> > > > > * Reliability: need more analysis
> > > > > * Stress: need more analysis
> > > > >
> > > > > As I remember Sean took pack200 tests. And Alexei Zakharov took
> > > > > security test crash.
> > > > > I'm going to sort things out with Eclipse unit tests 3.2 crash on
> > > > > Linux. And to look info failed jdktools test.
> > > > >
> > > > > So volunteers are required for: EGAx48, Geronimo, functional,
> > > > > reliability and stress suites.
> > > > >
> > > > > Also we have 2 JIRAs to be resolved for M3 under milstone unmblella[5]:
> > > > > https://issues.apache.org/jira/browse/HARMONY-4844
> > > > > https://issues.apache.org/jira/browse/HARMONY-4810
> > > > >
> > > > > [1] http://people.apache.org/~mloenko/snapshot_testing/script/r578410/index.html
> > > > > [2] http://people.apache.org/~mloenko/snapshot_testing/script/r551077/index.html
> > > > > [3] http://wiki.apache.org/harmony/milestones/M2
> > > > > [4] http://mail-archives.apache.org/mod_mbox/harmony-dev/200706.mbox/%3c678b3f320706290508l554079dau6af1a82b17d62b54@mail.gmail.com%3e
> > > > > [5] https://issues.apache.org/jira/browse/HARMONY-4843
> > > > >
> > > > > Thanks,
> > > > > Stepan.
> > > > >
> > > > >
> > > > > > Please feel free to pick up any issue for investigation. For example,
> > > > > > 2 pack200 classlib test failed. Also there is a crash of
> > > > > > org.apache.harmony.security.tests.java.security.cert.serialization.CertificateTest
> > > > > > on Linux x86
> > > > > >
> > > > > > BTW, should we consider BTI's workspace (that we use for M3 testing)
> > > > > > frozen too?
> > > > > >
> > > > > > [1] http://people.apache.org/~mloenko/snapshot_testing/script/r578410/index.html
> > > > > >
> > > > > > Thanks,
> > > > > > Stepan.
> > > > >
> > > >
> > > >
> > > > --
> > > > http://xiao-feng.blogspot.com
> > > >
> > >
> >
> >
> > --
> > http://xiao-feng.blogspot.com
> >
>
Re: [general] M3 - code frozen
Posted by Alexey Varlamov <al...@gmail.com>.
2007/9/26, Xiao-Feng Li <xi...@gmail.com>:
> On 9/26/07, Alexey Varlamov <al...@gmail.com> wrote:
> > Xiao-Feng,
> >
> > Idea is really interesting and it's a pity it came too late in M3. I
> > believe we're not going to prolong M3 closing date after this weekend
> > but OTOH suspect we have no spare hands to sort out critical x86-64
> > issues for remained days. I'd love someone rebut my doubts.
> > BTW, here is one of issues: self-hosting crashed on latest Linux-64 snapshot [1]
> >
> > [java] SIGSEGV in VM code.
> > [java] Stack trace:
> > [java] 0: gc_gen_adapt(GC_Gen*, long long) (??:-1)
> > [java] 1: pthread_mutex_unlock (??:-1)
> > [java] 2: apr_thread_mutex_unlock (locks/unix/thread_mutex.c:129)
> > [java] 3: apr_atomic_casptr (atomic/unix/apr_atomic.c:376)
> > [java] 4: log4cxx::helpers::ObjectImpl::releaseRef() const (??:-1)
> > [java] 5: gc_gen_reclaim_heap(GC_Gen*, long long) (??:-1)
> > [java] 6: pthread_mutex_unlock (??:-1)
> > [java] 7: apr_thread_mutex_unlock (locks/unix/thread_mutex.c:129)
> > [java] 8: ?? (??:-1)
> > [java] 9: gc_reclaim_heap(GC*, unsigned int) (??:-1)
> > [java] 10: pthread_mutex_lock (??:-1)
> > [java] 11: hymutex_lock (??:-1)
> > [java] 12: fspace_alloc(unsigned int, Allocator*) (??:-1)
> > [java] 13: nos_alloc(unsigned int, Allocator*) (??:-1)
> > [java] 14: gc_alloc (??:-1)
> > [java] 15: vm_new_vector(Class*, int) (??:-1)
> > [java] 16: vm_multianewarray_recursive(Class*, int*, unsigned int) (??:-1)
> > [java] 17: vm_rt_multianewarray_recursive(Class*, int*, unsigned
> > int) (??:-1)
> >
> > [1] http://people.apache.org/~smishura/r579330/Linux_x86_64/hdk_by_hdk/
>
> Alexey, I don't understand what you mean. Do you mean we should fix
> the failure immediately before we can consider a Linux64 M3 build?
Xiao-Feng,
Fix is always the best ;), but we need at least understand how
critical the failure is.
I assume we base milestone on achieving certain conscious level of
stability; then we need to evaluate known issues and decide if we
tolerate them for the moment. E.g. if some intermittent failure
appears quite often (and on reasonable workloads), do we want to call
this build stable?
--
Thanks,
Alexey
>
> Thanks,
> xiaofeng
>
> >
> > 2007/9/25, Xiao-Feng Li <xi...@gmail.com>:
> > > Hi, Stepan and folks,
> > >
> > > After looking at the testing results in the page given below, I feel
> > > the status of the revisionon X86-64 is quite "good". It is not
> > > perfect, but better than I expected. I'd suggest we consider to
> > > include X86-64 into our M3 build this time. It's an acceptable
> > > starting baseline, and we can improve it and will see better situation
> > > with M4, M5, etc.
> > >
> > > How do you guys think?
> > >
> > > Btw, The caveat for the X86-64 build is, they can only support up to
> > > 4GB heap size currently. Hopefully this will be changed in M4 or M5.
> > >
> > > PS, I checked the results in Linux64 for those "must pass" tests, such
> > > as Dacapo and "DRLVM tests". I found the two failures in "DRLVM tests"
> > > are "failures" rather than "errors", which I guess are actually
> > > time-out. The failure in Dacapo is with Chart, showing a null pointer
> > > in AWT. I personally think we can leave it as is for M3.
> > >
> > > Thanks,
> > > xiaofeng
> > >
> > >
> > > On 9/25/07, Stepan Mishura <st...@gmail.com> wrote:
> > > > On 9/24/07, Stepan Mishura <st...@gmail.com> wrote:
> > > > > On 9/22/07, Stepan Mishura wrote:
> > > > > > Hi,
> > > > > >
> > > > > > According to the plan - Sept. 22 is code freeze date for M3 so let's
> > > > > > follow policy:
> > > > > > "no more commits please without agreement from two committers on the dev list."
> > > > > >
> > > > > > Let's do more testing and analyze if there any critical/blocker issues
> > > > > > for consideration.
> > > > > > Please raise here issues that you think MUST be fixed for M3.
> > > > >
> > > > > Here is [1] the status of the last snapshot (r578410) that includes
> > > > > last classlib updates. Unfortunately, not everything is green there.
> > > > > I'm going to inspect all results to make sure that there are no
> > > > > failures caused by CC configuration issues.
> > > > >
> > > >
> > > > I've compared testing status for the last snapshot r578410 [1] with M2 [2][3].
> > > >
> > > > We have the following short status for failed suites:
> > > >
> > > > Windows_x86:
> > > > * classlib: 2 tests from pack200 module fail on snapshot (but pass
> > > > on debug build)
> > > > * Eclipse unit tests 3.2: there is no tests report like for M3. The
> > > > pass rate was improved from 99.32%[3] to 99.7%[1]
> > > > * Eclipse unit tests 3.3 are new and the pass rate is 99.77%. I
> > > > think is acceptable
> > > > * EGA x48 hours scenario fails. According to [4] it passed on M2.
> > > > * Functional: need more analysis, currently I see that 2 tests were
> > > > enabled and new 15 regressions.
> > > > * Geronimo: 2 regressions
> > > > * JDK tools: 1 test failed. It might be intermediate failure - the
> > > > test failed due to timeout
> > > > * Reliability: 65 tests passed for M2 and 64 for M3. Investigation
> > > > is required.
> > > > * Stress: 190 tests passed for M2 and 189 for M3. Investigation is required.
> > > >
> > > > Linux_x86:
> > > > * classlib: 2 tests from pack200 (as for Windows), 1 luni tests
> > > > failed and 1 crash of security test
> > > > * Eclipse unit tests 3.2: 2 suites crashed so pass rate is 69.60%. I
> > > > assume this may be CC host configuration issue. Going to investigate.
> > > > * Eclipse unit tests 3.3 are new and the pass rate is 96.47%. I
> > > > think is acceptable
> > > > * EGA x48 hours scenario: the same as for Windows (scenario fails on M3)
> > > > * Functional: need more analysis, similar to Windows - some test are
> > > > passing now but there are new failures.
> > > > * Geronimo: 2 regressions (the same as for Windows)
> > > > * Reliability: need more analysis
> > > > * Stress: need more analysis
> > > >
> > > > As I remember Sean took pack200 tests. And Alexei Zakharov took
> > > > security test crash.
> > > > I'm going to sort things out with Eclipse unit tests 3.2 crash on
> > > > Linux. And to look info failed jdktools test.
> > > >
> > > > So volunteers are required for: EGAx48, Geronimo, functional,
> > > > reliability and stress suites.
> > > >
> > > > Also we have 2 JIRAs to be resolved for M3 under milstone unmblella[5]:
> > > > https://issues.apache.org/jira/browse/HARMONY-4844
> > > > https://issues.apache.org/jira/browse/HARMONY-4810
> > > >
> > > > [1] http://people.apache.org/~mloenko/snapshot_testing/script/r578410/index.html
> > > > [2] http://people.apache.org/~mloenko/snapshot_testing/script/r551077/index.html
> > > > [3] http://wiki.apache.org/harmony/milestones/M2
> > > > [4] http://mail-archives.apache.org/mod_mbox/harmony-dev/200706.mbox/%3c678b3f320706290508l554079dau6af1a82b17d62b54@mail.gmail.com%3e
> > > > [5] https://issues.apache.org/jira/browse/HARMONY-4843
> > > >
> > > > Thanks,
> > > > Stepan.
> > > >
> > > >
> > > > > Please feel free to pick up any issue for investigation. For example,
> > > > > 2 pack200 classlib test failed. Also there is a crash of
> > > > > org.apache.harmony.security.tests.java.security.cert.serialization.CertificateTest
> > > > > on Linux x86
> > > > >
> > > > > BTW, should we consider BTI's workspace (that we use for M3 testing)
> > > > > frozen too?
> > > > >
> > > > > [1] http://people.apache.org/~mloenko/snapshot_testing/script/r578410/index.html
> > > > >
> > > > > Thanks,
> > > > > Stepan.
> > > >
> > >
> > >
> > > --
> > > http://xiao-feng.blogspot.com
> > >
> >
>
>
> --
> http://xiao-feng.blogspot.com
>
Re: [general] M3 - code frozen
Posted by Xiao-Feng Li <xi...@gmail.com>.
On 9/26/07, Alexey Varlamov <al...@gmail.com> wrote:
> Xiao-Feng,
>
> Idea is really interesting and it's a pity it came too late in M3. I
> believe we're not going to prolong M3 closing date after this weekend
> but OTOH suspect we have no spare hands to sort out critical x86-64
> issues for remained days. I'd love someone rebut my doubts.
> BTW, here is one of issues: self-hosting crashed on latest Linux-64 snapshot [1]
>
> [java] SIGSEGV in VM code.
> [java] Stack trace:
> [java] 0: gc_gen_adapt(GC_Gen*, long long) (??:-1)
> [java] 1: pthread_mutex_unlock (??:-1)
> [java] 2: apr_thread_mutex_unlock (locks/unix/thread_mutex.c:129)
> [java] 3: apr_atomic_casptr (atomic/unix/apr_atomic.c:376)
> [java] 4: log4cxx::helpers::ObjectImpl::releaseRef() const (??:-1)
> [java] 5: gc_gen_reclaim_heap(GC_Gen*, long long) (??:-1)
> [java] 6: pthread_mutex_unlock (??:-1)
> [java] 7: apr_thread_mutex_unlock (locks/unix/thread_mutex.c:129)
> [java] 8: ?? (??:-1)
> [java] 9: gc_reclaim_heap(GC*, unsigned int) (??:-1)
> [java] 10: pthread_mutex_lock (??:-1)
> [java] 11: hymutex_lock (??:-1)
> [java] 12: fspace_alloc(unsigned int, Allocator*) (??:-1)
> [java] 13: nos_alloc(unsigned int, Allocator*) (??:-1)
> [java] 14: gc_alloc (??:-1)
> [java] 15: vm_new_vector(Class*, int) (??:-1)
> [java] 16: vm_multianewarray_recursive(Class*, int*, unsigned int) (??:-1)
> [java] 17: vm_rt_multianewarray_recursive(Class*, int*, unsigned
> int) (??:-1)
>
> [1] http://people.apache.org/~smishura/r579330/Linux_x86_64/hdk_by_hdk/
Alexey, I don't understand what you mean. Do you mean we should fix
the failure immediately before we can consider a Linux64 M3 build?
Thanks,
xiaofeng
>
> 2007/9/25, Xiao-Feng Li <xi...@gmail.com>:
> > Hi, Stepan and folks,
> >
> > After looking at the testing results in the page given below, I feel
> > the status of the revisionon X86-64 is quite "good". It is not
> > perfect, but better than I expected. I'd suggest we consider to
> > include X86-64 into our M3 build this time. It's an acceptable
> > starting baseline, and we can improve it and will see better situation
> > with M4, M5, etc.
> >
> > How do you guys think?
> >
> > Btw, The caveat for the X86-64 build is, they can only support up to
> > 4GB heap size currently. Hopefully this will be changed in M4 or M5.
> >
> > PS, I checked the results in Linux64 for those "must pass" tests, such
> > as Dacapo and "DRLVM tests". I found the two failures in "DRLVM tests"
> > are "failures" rather than "errors", which I guess are actually
> > time-out. The failure in Dacapo is with Chart, showing a null pointer
> > in AWT. I personally think we can leave it as is for M3.
> >
> > Thanks,
> > xiaofeng
> >
> >
> > On 9/25/07, Stepan Mishura <st...@gmail.com> wrote:
> > > On 9/24/07, Stepan Mishura <st...@gmail.com> wrote:
> > > > On 9/22/07, Stepan Mishura wrote:
> > > > > Hi,
> > > > >
> > > > > According to the plan - Sept. 22 is code freeze date for M3 so let's
> > > > > follow policy:
> > > > > "no more commits please without agreement from two committers on the dev list."
> > > > >
> > > > > Let's do more testing and analyze if there any critical/blocker issues
> > > > > for consideration.
> > > > > Please raise here issues that you think MUST be fixed for M3.
> > > >
> > > > Here is [1] the status of the last snapshot (r578410) that includes
> > > > last classlib updates. Unfortunately, not everything is green there.
> > > > I'm going to inspect all results to make sure that there are no
> > > > failures caused by CC configuration issues.
> > > >
> > >
> > > I've compared testing status for the last snapshot r578410 [1] with M2 [2][3].
> > >
> > > We have the following short status for failed suites:
> > >
> > > Windows_x86:
> > > * classlib: 2 tests from pack200 module fail on snapshot (but pass
> > > on debug build)
> > > * Eclipse unit tests 3.2: there is no tests report like for M3. The
> > > pass rate was improved from 99.32%[3] to 99.7%[1]
> > > * Eclipse unit tests 3.3 are new and the pass rate is 99.77%. I
> > > think is acceptable
> > > * EGA x48 hours scenario fails. According to [4] it passed on M2.
> > > * Functional: need more analysis, currently I see that 2 tests were
> > > enabled and new 15 regressions.
> > > * Geronimo: 2 regressions
> > > * JDK tools: 1 test failed. It might be intermediate failure - the
> > > test failed due to timeout
> > > * Reliability: 65 tests passed for M2 and 64 for M3. Investigation
> > > is required.
> > > * Stress: 190 tests passed for M2 and 189 for M3. Investigation is required.
> > >
> > > Linux_x86:
> > > * classlib: 2 tests from pack200 (as for Windows), 1 luni tests
> > > failed and 1 crash of security test
> > > * Eclipse unit tests 3.2: 2 suites crashed so pass rate is 69.60%. I
> > > assume this may be CC host configuration issue. Going to investigate.
> > > * Eclipse unit tests 3.3 are new and the pass rate is 96.47%. I
> > > think is acceptable
> > > * EGA x48 hours scenario: the same as for Windows (scenario fails on M3)
> > > * Functional: need more analysis, similar to Windows - some test are
> > > passing now but there are new failures.
> > > * Geronimo: 2 regressions (the same as for Windows)
> > > * Reliability: need more analysis
> > > * Stress: need more analysis
> > >
> > > As I remember Sean took pack200 tests. And Alexei Zakharov took
> > > security test crash.
> > > I'm going to sort things out with Eclipse unit tests 3.2 crash on
> > > Linux. And to look info failed jdktools test.
> > >
> > > So volunteers are required for: EGAx48, Geronimo, functional,
> > > reliability and stress suites.
> > >
> > > Also we have 2 JIRAs to be resolved for M3 under milstone unmblella[5]:
> > > https://issues.apache.org/jira/browse/HARMONY-4844
> > > https://issues.apache.org/jira/browse/HARMONY-4810
> > >
> > > [1] http://people.apache.org/~mloenko/snapshot_testing/script/r578410/index.html
> > > [2] http://people.apache.org/~mloenko/snapshot_testing/script/r551077/index.html
> > > [3] http://wiki.apache.org/harmony/milestones/M2
> > > [4] http://mail-archives.apache.org/mod_mbox/harmony-dev/200706.mbox/%3c678b3f320706290508l554079dau6af1a82b17d62b54@mail.gmail.com%3e
> > > [5] https://issues.apache.org/jira/browse/HARMONY-4843
> > >
> > > Thanks,
> > > Stepan.
> > >
> > >
> > > > Please feel free to pick up any issue for investigation. For example,
> > > > 2 pack200 classlib test failed. Also there is a crash of
> > > > org.apache.harmony.security.tests.java.security.cert.serialization.CertificateTest
> > > > on Linux x86
> > > >
> > > > BTW, should we consider BTI's workspace (that we use for M3 testing)
> > > > frozen too?
> > > >
> > > > [1] http://people.apache.org/~mloenko/snapshot_testing/script/r578410/index.html
> > > >
> > > > Thanks,
> > > > Stepan.
> > >
> >
> >
> > --
> > http://xiao-feng.blogspot.com
> >
>
--
http://xiao-feng.blogspot.com
Re: [general] M3 - code frozen
Posted by Alexey Varlamov <al...@gmail.com>.
Xiao-Feng,
Idea is really interesting and it's a pity it came too late in M3. I
believe we're not going to prolong M3 closing date after this weekend
but OTOH suspect we have no spare hands to sort out critical x86-64
issues for remained days. I'd love someone rebut my doubts.
BTW, here is one of issues: self-hosting crashed on latest Linux-64 snapshot [1]
[java] SIGSEGV in VM code.
[java] Stack trace:
[java] 0: gc_gen_adapt(GC_Gen*, long long) (??:-1)
[java] 1: pthread_mutex_unlock (??:-1)
[java] 2: apr_thread_mutex_unlock (locks/unix/thread_mutex.c:129)
[java] 3: apr_atomic_casptr (atomic/unix/apr_atomic.c:376)
[java] 4: log4cxx::helpers::ObjectImpl::releaseRef() const (??:-1)
[java] 5: gc_gen_reclaim_heap(GC_Gen*, long long) (??:-1)
[java] 6: pthread_mutex_unlock (??:-1)
[java] 7: apr_thread_mutex_unlock (locks/unix/thread_mutex.c:129)
[java] 8: ?? (??:-1)
[java] 9: gc_reclaim_heap(GC*, unsigned int) (??:-1)
[java] 10: pthread_mutex_lock (??:-1)
[java] 11: hymutex_lock (??:-1)
[java] 12: fspace_alloc(unsigned int, Allocator*) (??:-1)
[java] 13: nos_alloc(unsigned int, Allocator*) (??:-1)
[java] 14: gc_alloc (??:-1)
[java] 15: vm_new_vector(Class*, int) (??:-1)
[java] 16: vm_multianewarray_recursive(Class*, int*, unsigned int) (??:-1)
[java] 17: vm_rt_multianewarray_recursive(Class*, int*, unsigned
int) (??:-1)
[1] http://people.apache.org/~smishura/r579330/Linux_x86_64/hdk_by_hdk/
2007/9/25, Xiao-Feng Li <xi...@gmail.com>:
> Hi, Stepan and folks,
>
> After looking at the testing results in the page given below, I feel
> the status of the revisionon X86-64 is quite "good". It is not
> perfect, but better than I expected. I'd suggest we consider to
> include X86-64 into our M3 build this time. It's an acceptable
> starting baseline, and we can improve it and will see better situation
> with M4, M5, etc.
>
> How do you guys think?
>
> Btw, The caveat for the X86-64 build is, they can only support up to
> 4GB heap size currently. Hopefully this will be changed in M4 or M5.
>
> PS, I checked the results in Linux64 for those "must pass" tests, such
> as Dacapo and "DRLVM tests". I found the two failures in "DRLVM tests"
> are "failures" rather than "errors", which I guess are actually
> time-out. The failure in Dacapo is with Chart, showing a null pointer
> in AWT. I personally think we can leave it as is for M3.
>
> Thanks,
> xiaofeng
>
>
> On 9/25/07, Stepan Mishura <st...@gmail.com> wrote:
> > On 9/24/07, Stepan Mishura <st...@gmail.com> wrote:
> > > On 9/22/07, Stepan Mishura wrote:
> > > > Hi,
> > > >
> > > > According to the plan - Sept. 22 is code freeze date for M3 so let's
> > > > follow policy:
> > > > "no more commits please without agreement from two committers on the dev list."
> > > >
> > > > Let's do more testing and analyze if there any critical/blocker issues
> > > > for consideration.
> > > > Please raise here issues that you think MUST be fixed for M3.
> > >
> > > Here is [1] the status of the last snapshot (r578410) that includes
> > > last classlib updates. Unfortunately, not everything is green there.
> > > I'm going to inspect all results to make sure that there are no
> > > failures caused by CC configuration issues.
> > >
> >
> > I've compared testing status for the last snapshot r578410 [1] with M2 [2][3].
> >
> > We have the following short status for failed suites:
> >
> > Windows_x86:
> > * classlib: 2 tests from pack200 module fail on snapshot (but pass
> > on debug build)
> > * Eclipse unit tests 3.2: there is no tests report like for M3. The
> > pass rate was improved from 99.32%[3] to 99.7%[1]
> > * Eclipse unit tests 3.3 are new and the pass rate is 99.77%. I
> > think is acceptable
> > * EGA x48 hours scenario fails. According to [4] it passed on M2.
> > * Functional: need more analysis, currently I see that 2 tests were
> > enabled and new 15 regressions.
> > * Geronimo: 2 regressions
> > * JDK tools: 1 test failed. It might be intermediate failure - the
> > test failed due to timeout
> > * Reliability: 65 tests passed for M2 and 64 for M3. Investigation
> > is required.
> > * Stress: 190 tests passed for M2 and 189 for M3. Investigation is required.
> >
> > Linux_x86:
> > * classlib: 2 tests from pack200 (as for Windows), 1 luni tests
> > failed and 1 crash of security test
> > * Eclipse unit tests 3.2: 2 suites crashed so pass rate is 69.60%. I
> > assume this may be CC host configuration issue. Going to investigate.
> > * Eclipse unit tests 3.3 are new and the pass rate is 96.47%. I
> > think is acceptable
> > * EGA x48 hours scenario: the same as for Windows (scenario fails on M3)
> > * Functional: need more analysis, similar to Windows - some test are
> > passing now but there are new failures.
> > * Geronimo: 2 regressions (the same as for Windows)
> > * Reliability: need more analysis
> > * Stress: need more analysis
> >
> > As I remember Sean took pack200 tests. And Alexei Zakharov took
> > security test crash.
> > I'm going to sort things out with Eclipse unit tests 3.2 crash on
> > Linux. And to look info failed jdktools test.
> >
> > So volunteers are required for: EGAx48, Geronimo, functional,
> > reliability and stress suites.
> >
> > Also we have 2 JIRAs to be resolved for M3 under milstone unmblella[5]:
> > https://issues.apache.org/jira/browse/HARMONY-4844
> > https://issues.apache.org/jira/browse/HARMONY-4810
> >
> > [1] http://people.apache.org/~mloenko/snapshot_testing/script/r578410/index.html
> > [2] http://people.apache.org/~mloenko/snapshot_testing/script/r551077/index.html
> > [3] http://wiki.apache.org/harmony/milestones/M2
> > [4] http://mail-archives.apache.org/mod_mbox/harmony-dev/200706.mbox/%3c678b3f320706290508l554079dau6af1a82b17d62b54@mail.gmail.com%3e
> > [5] https://issues.apache.org/jira/browse/HARMONY-4843
> >
> > Thanks,
> > Stepan.
> >
> >
> > > Please feel free to pick up any issue for investigation. For example,
> > > 2 pack200 classlib test failed. Also there is a crash of
> > > org.apache.harmony.security.tests.java.security.cert.serialization.CertificateTest
> > > on Linux x86
> > >
> > > BTW, should we consider BTI's workspace (that we use for M3 testing)
> > > frozen too?
> > >
> > > [1] http://people.apache.org/~mloenko/snapshot_testing/script/r578410/index.html
> > >
> > > Thanks,
> > > Stepan.
> >
>
>
> --
> http://xiao-feng.blogspot.com
>
Re: [general] M3 - code frozen
Posted by Xiao-Feng Li <xi...@gmail.com>.
Hi, Stepan and folks,
After looking at the testing results in the page given below, I feel
the status of the revisionon X86-64 is quite "good". It is not
perfect, but better than I expected. I'd suggest we consider to
include X86-64 into our M3 build this time. It's an acceptable
starting baseline, and we can improve it and will see better situation
with M4, M5, etc.
How do you guys think?
Btw, The caveat for the X86-64 build is, they can only support up to
4GB heap size currently. Hopefully this will be changed in M4 or M5.
PS, I checked the results in Linux64 for those "must pass" tests, such
as Dacapo and "DRLVM tests". I found the two failures in "DRLVM tests"
are "failures" rather than "errors", which I guess are actually
time-out. The failure in Dacapo is with Chart, showing a null pointer
in AWT. I personally think we can leave it as is for M3.
Thanks,
xiaofeng
On 9/25/07, Stepan Mishura <st...@gmail.com> wrote:
> On 9/24/07, Stepan Mishura <st...@gmail.com> wrote:
> > On 9/22/07, Stepan Mishura wrote:
> > > Hi,
> > >
> > > According to the plan - Sept. 22 is code freeze date for M3 so let's
> > > follow policy:
> > > "no more commits please without agreement from two committers on the dev list."
> > >
> > > Let's do more testing and analyze if there any critical/blocker issues
> > > for consideration.
> > > Please raise here issues that you think MUST be fixed for M3.
> >
> > Here is [1] the status of the last snapshot (r578410) that includes
> > last classlib updates. Unfortunately, not everything is green there.
> > I'm going to inspect all results to make sure that there are no
> > failures caused by CC configuration issues.
> >
>
> I've compared testing status for the last snapshot r578410 [1] with M2 [2][3].
>
> We have the following short status for failed suites:
>
> Windows_x86:
> * classlib: 2 tests from pack200 module fail on snapshot (but pass
> on debug build)
> * Eclipse unit tests 3.2: there is no tests report like for M3. The
> pass rate was improved from 99.32%[3] to 99.7%[1]
> * Eclipse unit tests 3.3 are new and the pass rate is 99.77%. I
> think is acceptable
> * EGA x48 hours scenario fails. According to [4] it passed on M2.
> * Functional: need more analysis, currently I see that 2 tests were
> enabled and new 15 regressions.
> * Geronimo: 2 regressions
> * JDK tools: 1 test failed. It might be intermediate failure - the
> test failed due to timeout
> * Reliability: 65 tests passed for M2 and 64 for M3. Investigation
> is required.
> * Stress: 190 tests passed for M2 and 189 for M3. Investigation is required.
>
> Linux_x86:
> * classlib: 2 tests from pack200 (as for Windows), 1 luni tests
> failed and 1 crash of security test
> * Eclipse unit tests 3.2: 2 suites crashed so pass rate is 69.60%. I
> assume this may be CC host configuration issue. Going to investigate.
> * Eclipse unit tests 3.3 are new and the pass rate is 96.47%. I
> think is acceptable
> * EGA x48 hours scenario: the same as for Windows (scenario fails on M3)
> * Functional: need more analysis, similar to Windows - some test are
> passing now but there are new failures.
> * Geronimo: 2 regressions (the same as for Windows)
> * Reliability: need more analysis
> * Stress: need more analysis
>
> As I remember Sean took pack200 tests. And Alexei Zakharov took
> security test crash.
> I'm going to sort things out with Eclipse unit tests 3.2 crash on
> Linux. And to look info failed jdktools test.
>
> So volunteers are required for: EGAx48, Geronimo, functional,
> reliability and stress suites.
>
> Also we have 2 JIRAs to be resolved for M3 under milstone unmblella[5]:
> https://issues.apache.org/jira/browse/HARMONY-4844
> https://issues.apache.org/jira/browse/HARMONY-4810
>
> [1] http://people.apache.org/~mloenko/snapshot_testing/script/r578410/index.html
> [2] http://people.apache.org/~mloenko/snapshot_testing/script/r551077/index.html
> [3] http://wiki.apache.org/harmony/milestones/M2
> [4] http://mail-archives.apache.org/mod_mbox/harmony-dev/200706.mbox/%3c678b3f320706290508l554079dau6af1a82b17d62b54@mail.gmail.com%3e
> [5] https://issues.apache.org/jira/browse/HARMONY-4843
>
> Thanks,
> Stepan.
>
>
> > Please feel free to pick up any issue for investigation. For example,
> > 2 pack200 classlib test failed. Also there is a crash of
> > org.apache.harmony.security.tests.java.security.cert.serialization.CertificateTest
> > on Linux x86
> >
> > BTW, should we consider BTI's workspace (that we use for M3 testing)
> > frozen too?
> >
> > [1] http://people.apache.org/~mloenko/snapshot_testing/script/r578410/index.html
> >
> > Thanks,
> > Stepan.
>
--
http://xiao-feng.blogspot.com
Re: [general] M3 - code frozen
Posted by "Pavlenko, Andrey A" <an...@googlemail.com>.
Here is my evaluation of the func test suite failures.
> functional.org.apache.harmony.test.func.api.java.awt.FontMetrics
Invalid test. HARMONY-4859
>
functional.org.apache.harmony.test.func.api.java.beans.introspector.surveymethods.property
HARMONY-4861. Not a regression, it was failing in M2 too.
> functional.org.apache.harmony.test.func.api.java.io.BufferedOutputStream
Invalid test. HARMONY-4864
> functional.org.apache.harmony.test.func.api.java.io.DataOutputStream
Invalid test. HARMONY-4864
> functional.org.apache.harmony.test.func.api.java.net.Socket
Looks like invalid test. Failed in M2, also fails on RI.
> functional.org.apache.harmony.test.func.api.java.nio.channels.fileChannel
Looks like invalid test. Failed in M2, also fails on RI.
>
functional.org.apache.harmony.test.func.api.java.nio.F_MappedByteBufferTest_01
Looks like invalid test. Failed in M2, also fails on RI.
> functional.org.apache.harmony.test.func.jit.HLO.hvn.Volatile1
Intermittent. I'm not able to reproduce the failure
> functional.org.apache.harmony.test.func.jit.HLO.lazyexc.IO2
Intermittent. I'm not able to reproduce the failure
> functional.org.apache.harmony.test.func.reg.jit.btest5153
Regression! HARMONY-4866
> functional.org.apache.harmony.test.func.reg.vm.btest6572
I'm not sure if it's a regression or incorrect test, however I've filed
an issue - HARMONY-4867
So, we have 1 regression - HARMONY-4866 and 1 possible regression -
HARMONY-4867, but I'm not sure about this issue.
On 9/27/07, Pavlenko, Andrey A <an...@googlemail.com> wrote:
>
> I've investigated the errors of the func tests. Please see my comments
> below.
>
> >
> functional.org.apache.harmony.test.func.api.java.security.F_KeyFactoryTest_01
> HARMONY-4857
> > functional.org.apache.harmony.test.func.api.javax.swing.AbstractButton Intermittent. Always passes in a single mode.
>
> The following tests fail because they are too heavy and sometimes they are
> not finishing in 300 sec (default timeout). For example, some tests perform
> several millions of iterations... I'm not sure if it's required to do so
> many iterations, but if it's so the timeout should be increased. Also these
> tests pass if I decrease concurrency to 2. By default the tests are running
> in 4 threads.
> > functional.org.apache.harmony.test.func.api.java.io.DataInputStream
> Timeout
> > functional.org.apache.harmony.test.func.jit.HLO.abcd.Test1
> Timeout
> > functional.org.apache.harmony.test.func.jit.HLO.lazyexc.ExcObjectUse2 Timeout
> > functional.org.apache.harmony.test.func.jit.HLO.peel.ExceptionLoop
> Timeout
> > functional.org.apache.harmony.test.func.jit.HLO.peel.LoopVar2
> Timeout
> > functional.org.apache.harmony.test.func.jit.HLO.peel.TryCatch4
> Timeout
> > functional.org.apache.harmony.test.func.reg.vm.btest1355
> Timeout
> > functional.org.apache.harmony.test.func.jit.HLO.uce.unreachathrow
> Timeout. Too many iterations - 20000000. the test pass in ~45s if I
> decrease the number of iterations to 500000
>
> So, it looks like there is 1 regression - HARMONY-4857.
>
> On 9/26/07, Pavlenko, Andrey A <andrey.a.pavlenko@googlemail.com > wrote:
> >
> > I'm looking at the func tests failures. I've just filed new issue
> > causing error of one of the func tests - HARMONY-4857.
> >
> > On 9/25/07, Stepan Mishura <st...@gmail.com> wrote:
> > >
> > > On 9/24/07, Stepan Mishura <st...@gmail.com> wrote:
> > > > On 9/22/07, Stepan Mishura wrote:
> > > > > Hi,
> > > > >
> > > > > According to the plan - Sept. 22 is code freeze date for M3 so
> > > let's
> > > > > follow policy:
> > > > > "no more commits please without agreement from two committers on
> > > the dev list."
> > > > >
> > > > > Let's do more testing and analyze if there any critical/blocker
> > > issues
> > > > > for consideration.
> > > > > Please raise here issues that you think MUST be fixed for M3.
> > > >
> > > > Here is [1] the status of the last snapshot (r578410) that includes
> > > > last classlib updates. Unfortunately, not everything is green there.
> > >
> > > > I'm going to inspect all results to make sure that there are no
> > > > failures caused by CC configuration issues.
> > > >
> > >
> > > I've compared testing status for the last snapshot r578410 [1] with M2
> > > [2][3].
> > >
> > > We have the following short status for failed suites:
> > >
> > > Windows_x86:
> > > * classlib: 2 tests from pack200 module fail on snapshot (but pass
> > > on debug build)
> > > * Eclipse unit tests 3.2: there is no tests report like for M3. The
> > > pass rate was improved from 99.32%[3] to 99.7%[1]
> > > * Eclipse unit tests 3.3 are new and the pass rate is 99.77%. I
> > > think is acceptable
> > > * EGA x48 hours scenario fails. According to [4] it passed on M2.
> > > * Functional: need more analysis, currently I see that 2 tests were
> > > enabled and new 15 regressions.
> > > * Geronimo: 2 regressions
> > > * JDK tools: 1 test failed. It might be intermediate failure - the
> > > test failed due to timeout
> > > * Reliability: 65 tests passed for M2 and 64 for M3. Investigation
> > > is required.
> > > * Stress: 190 tests passed for M2 and 189 for M3. Investigation is
> > > required.
> > >
> > > Linux_x86:
> > > * classlib: 2 tests from pack200 (as for Windows), 1 luni tests
> > > failed and 1 crash of security test
> > > * Eclipse unit tests 3.2: 2 suites crashed so pass rate is 69.60%. I
> > > assume this may be CC host configuration issue. Going to investigate.
> > > * Eclipse unit tests 3.3 are new and the pass rate is 96.47%. I
> > > think is acceptable
> > > * EGA x48 hours scenario: the same as for Windows (scenario fails on
> > > M3)
> > > * Functional: need more analysis, similar to Windows - some test are
> > > passing now but there are new failures.
> > > * Geronimo: 2 regressions (the same as for Windows)
> > > * Reliability: need more analysis
> > > * Stress: need more analysis
> > >
> > > As I remember Sean took pack200 tests. And Alexei Zakharov took
> > > security test crash.
> > > I'm going to sort things out with Eclipse unit tests 3.2 crash on
> > > Linux. And to look info failed jdktools test.
> > >
> > > So volunteers are required for: EGAx48, Geronimo, functional,
> > > reliability and stress suites.
> > >
> > > Also we have 2 JIRAs to be resolved for M3 under milstone
> > > unmblella[5]:
> > > https://issues.apache.org/jira/browse/HARMONY-4844
> > > https://issues.apache.org/jira/browse/HARMONY-4810
> > >
> > > [1] http://people.apache.org/~mloenko/snapshot_testing/script/r578410/index.html
> > >
> > > <http://people.apache.org/%7Emloenko/snapshot_testing/script/r578410/index.html>
> > > [2]
> > > http://people.apache.org/~mloenko/snapshot_testing/script/r551077/index.html<http://people.apache.org/%7Emloenko/snapshot_testing/script/r551077/index.html>
> > > [3] http://wiki.apache.org/harmony/milestones/M2
> > > [4]
> > > http://mail-archives.apache.org/mod_mbox/harmony-dev/200706.mbox/%3c678b3f320706290508l554079dau6af1a82b17d62b54@mail.gmail.com%3e
> > > [5] https://issues.apache.org/jira/browse/HARMONY-4843
> > >
> > > Thanks,
> > > Stepan.
> > >
> > >
> > > > Please feel free to pick up any issue for investigation. For
> > > example,
> > > > 2 pack200 classlib test failed. Also there is a crash of
> > > >
> > > org.apache.harmony.security.tests.java.security.cert.serialization.CertificateTest
> > > > on Linux x86
> > > >
> > > > BTW, should we consider BTI's workspace (that we use for M3 testing)
> > > > frozen too?
> > > >
> > > > [1]
> > > http://people.apache.org/~mloenko/snapshot_testing/script/r578410/index.html<http://people.apache.org/%7Emloenko/snapshot_testing/script/r578410/index.html>
> > > >
> > > > Thanks,
> > > > Stepan.
> > >
> >
> >
>
Re: [general] M3 - code frozen
Posted by "Pavlenko, Andrey A" <an...@googlemail.com>.
I've investigated the errors of the func tests. Please see my comments
below.
>
functional.org.apache.harmony.test.func.api.java.security.F_KeyFactoryTest_01
HARMONY-4857
> functional.org.apache.harmony.test.func.api.javax.swing.AbstractButton
Intermittent. Always passes in a single mode.
The following tests fail because they are too heavy and sometimes they are
not finishing in 300 sec (default timeout). For example, some tests perform
several millions of iterations... I'm not sure if it's required to do so
many iterations, but if it's so the timeout should be increased. Also these
tests pass if I decrease concurrency to 2. By default the tests are running
in 4 threads.
> functional.org.apache.harmony.test.func.api.java.io.DataInputStream
Timeout
> functional.org.apache.harmony.test.func.jit.HLO.abcd.Test1
Timeout
> functional.org.apache.harmony.test.func.jit.HLO.lazyexc.ExcObjectUse2
Timeout
> functional.org.apache.harmony.test.func.jit.HLO.peel.ExceptionLoop
Timeout
> functional.org.apache.harmony.test.func.jit.HLO.peel.LoopVar2
Timeout
> functional.org.apache.harmony.test.func.jit.HLO.peel.TryCatch4
Timeout
> functional.org.apache.harmony.test.func.reg.vm.btest1355
Timeout
> functional.org.apache.harmony.test.func.jit.HLO.uce.unreachathrow
Timeout. Too many iterations - 20000000. the test pass in ~45s if I
decrease the number of iterations to 500000
So, it looks like there is 1 regression - HARMONY-4857.
On 9/26/07, Pavlenko, Andrey A <an...@googlemail.com> wrote:
>
> I'm looking at the func tests failures. I've just filed new issue causing
> error of one of the func tests - HARMONY-4857.
>
> On 9/25/07, Stepan Mishura <st...@gmail.com> wrote:
> >
> > On 9/24/07, Stepan Mishura <st...@gmail.com> wrote:
> > > On 9/22/07, Stepan Mishura wrote:
> > > > Hi,
> > > >
> > > > According to the plan - Sept. 22 is code freeze date for M3 so let's
> >
> > > > follow policy:
> > > > "no more commits please without agreement from two committers on the
> > dev list."
> > > >
> > > > Let's do more testing and analyze if there any critical/blocker
> > issues
> > > > for consideration.
> > > > Please raise here issues that you think MUST be fixed for M3.
> > >
> > > Here is [1] the status of the last snapshot (r578410) that includes
> > > last classlib updates. Unfortunately, not everything is green there.
> > > I'm going to inspect all results to make sure that there are no
> > > failures caused by CC configuration issues.
> > >
> >
> > I've compared testing status for the last snapshot r578410 [1] with M2
> > [2][3].
> >
> > We have the following short status for failed suites:
> >
> > Windows_x86:
> > * classlib: 2 tests from pack200 module fail on snapshot (but pass
> > on debug build)
> > * Eclipse unit tests 3.2: there is no tests report like for M3. The
> > pass rate was improved from 99.32%[3] to 99.7%[1]
> > * Eclipse unit tests 3.3 are new and the pass rate is 99.77%. I
> > think is acceptable
> > * EGA x48 hours scenario fails. According to [4] it passed on M2.
> > * Functional: need more analysis, currently I see that 2 tests were
> > enabled and new 15 regressions.
> > * Geronimo: 2 regressions
> > * JDK tools: 1 test failed. It might be intermediate failure - the
> > test failed due to timeout
> > * Reliability: 65 tests passed for M2 and 64 for M3. Investigation
> > is required.
> > * Stress: 190 tests passed for M2 and 189 for M3. Investigation is
> > required.
> >
> > Linux_x86:
> > * classlib: 2 tests from pack200 (as for Windows), 1 luni tests
> > failed and 1 crash of security test
> > * Eclipse unit tests 3.2: 2 suites crashed so pass rate is 69.60%. I
> > assume this may be CC host configuration issue. Going to investigate.
> > * Eclipse unit tests 3.3 are new and the pass rate is 96.47%. I
> > think is acceptable
> > * EGA x48 hours scenario: the same as for Windows (scenario fails on
> > M3)
> > * Functional: need more analysis, similar to Windows - some test are
> > passing now but there are new failures.
> > * Geronimo: 2 regressions (the same as for Windows)
> > * Reliability: need more analysis
> > * Stress: need more analysis
> >
> > As I remember Sean took pack200 tests. And Alexei Zakharov took
> > security test crash.
> > I'm going to sort things out with Eclipse unit tests 3.2 crash on
> > Linux. And to look info failed jdktools test.
> >
> > So volunteers are required for: EGAx48, Geronimo, functional,
> > reliability and stress suites.
> >
> > Also we have 2 JIRAs to be resolved for M3 under milstone unmblella[5]:
> > https://issues.apache.org/jira/browse/HARMONY-4844
> > https://issues.apache.org/jira/browse/HARMONY-4810
> >
> > [1]
> > http://people.apache.org/~mloenko/snapshot_testing/script/r578410/index.html<http://people.apache.org/%7Emloenko/snapshot_testing/script/r578410/index.html>
> > [2]
> > http://people.apache.org/~mloenko/snapshot_testing/script/r551077/index.html<http://people.apache.org/%7Emloenko/snapshot_testing/script/r551077/index.html>
> > [3] http://wiki.apache.org/harmony/milestones/M2
> > [4]
> > http://mail-archives.apache.org/mod_mbox/harmony-dev/200706.mbox/%3c678b3f320706290508l554079dau6af1a82b17d62b54@mail.gmail.com%3e
> > [5] https://issues.apache.org/jira/browse/HARMONY-4843
> >
> > Thanks,
> > Stepan.
> >
> >
> > > Please feel free to pick up any issue for investigation. For example,
> > > 2 pack200 classlib test failed. Also there is a crash of
> > >
> > org.apache.harmony.security.tests.java.security.cert.serialization.CertificateTest
> > > on Linux x86
> > >
> > > BTW, should we consider BTI's workspace (that we use for M3 testing)
> > > frozen too?
> > >
> > > [1]
> > http://people.apache.org/~mloenko/snapshot_testing/script/r578410/index.html<http://people.apache.org/%7Emloenko/snapshot_testing/script/r578410/index.html>
> > >
> > > Thanks,
> > > Stepan.
> >
>
>
Re: [general] M3 - code frozen
Posted by "Pavlenko, Andrey A" <an...@googlemail.com>.
I'm looking at the func tests failures. I've just filed new issue causing
error of one of the func tests - HARMONY-4857.
On 9/25/07, Stepan Mishura <st...@gmail.com> wrote:
>
> On 9/24/07, Stepan Mishura <st...@gmail.com> wrote:
> > On 9/22/07, Stepan Mishura wrote:
> > > Hi,
> > >
> > > According to the plan - Sept. 22 is code freeze date for M3 so let's
> > > follow policy:
> > > "no more commits please without agreement from two committers on the
> dev list."
> > >
> > > Let's do more testing and analyze if there any critical/blocker issues
> > > for consideration.
> > > Please raise here issues that you think MUST be fixed for M3.
> >
> > Here is [1] the status of the last snapshot (r578410) that includes
> > last classlib updates. Unfortunately, not everything is green there.
> > I'm going to inspect all results to make sure that there are no
> > failures caused by CC configuration issues.
> >
>
> I've compared testing status for the last snapshot r578410 [1] with M2
> [2][3].
>
> We have the following short status for failed suites:
>
> Windows_x86:
> * classlib: 2 tests from pack200 module fail on snapshot (but pass
> on debug build)
> * Eclipse unit tests 3.2: there is no tests report like for M3. The
> pass rate was improved from 99.32%[3] to 99.7%[1]
> * Eclipse unit tests 3.3 are new and the pass rate is 99.77%. I
> think is acceptable
> * EGA x48 hours scenario fails. According to [4] it passed on M2.
> * Functional: need more analysis, currently I see that 2 tests were
> enabled and new 15 regressions.
> * Geronimo: 2 regressions
> * JDK tools: 1 test failed. It might be intermediate failure - the
> test failed due to timeout
> * Reliability: 65 tests passed for M2 and 64 for M3. Investigation
> is required.
> * Stress: 190 tests passed for M2 and 189 for M3. Investigation is
> required.
>
> Linux_x86:
> * classlib: 2 tests from pack200 (as for Windows), 1 luni tests
> failed and 1 crash of security test
> * Eclipse unit tests 3.2: 2 suites crashed so pass rate is 69.60%. I
> assume this may be CC host configuration issue. Going to investigate.
> * Eclipse unit tests 3.3 are new and the pass rate is 96.47%. I
> think is acceptable
> * EGA x48 hours scenario: the same as for Windows (scenario fails on M3)
> * Functional: need more analysis, similar to Windows - some test are
> passing now but there are new failures.
> * Geronimo: 2 regressions (the same as for Windows)
> * Reliability: need more analysis
> * Stress: need more analysis
>
> As I remember Sean took pack200 tests. And Alexei Zakharov took
> security test crash.
> I'm going to sort things out with Eclipse unit tests 3.2 crash on
> Linux. And to look info failed jdktools test.
>
> So volunteers are required for: EGAx48, Geronimo, functional,
> reliability and stress suites.
>
> Also we have 2 JIRAs to be resolved for M3 under milstone unmblella[5]:
> https://issues.apache.org/jira/browse/HARMONY-4844
> https://issues.apache.org/jira/browse/HARMONY-4810
>
> [1]
> http://people.apache.org/~mloenko/snapshot_testing/script/r578410/index.html
> [2]
> http://people.apache.org/~mloenko/snapshot_testing/script/r551077/index.html
> [3] http://wiki.apache.org/harmony/milestones/M2
> [4]
> http://mail-archives.apache.org/mod_mbox/harmony-dev/200706.mbox/%3c678b3f320706290508l554079dau6af1a82b17d62b54@mail.gmail.com%3e
> [5] https://issues.apache.org/jira/browse/HARMONY-4843
>
> Thanks,
> Stepan.
>
>
> > Please feel free to pick up any issue for investigation. For example,
> > 2 pack200 classlib test failed. Also there is a crash of
> >
> org.apache.harmony.security.tests.java.security.cert.serialization.CertificateTest
> > on Linux x86
> >
> > BTW, should we consider BTI's workspace (that we use for M3 testing)
> > frozen too?
> >
> > [1]
> http://people.apache.org/~mloenko/snapshot_testing/script/r578410/index.html
> >
> > Thanks,
> > Stepan.
>
Re: [general] M3 - code frozen
Posted by Eugene Ostrovsky <eu...@gmail.com>.
Stepan,
I've run the failed TPTP test 1000 times on harmony M2 and M3 snapshots:
M2: 35 failures (1000 runs)
M3: 36 failures (1000 runs)
This results prove that:
1. This failure is intermittent (~3.5% failures)
2. This is not a regression relative to M2
The similar results I've got for JDKTools failed test
org.apache.harmony.jpda.tests.jdwp.MultiSession.RefTypeIDTest:
M2: 14 failures (1000 runs)
M3: 12 failures (1000 runs)
Thanks,
Eugene.
On 9/25/07, Stepan Mishura <st...@gmail.com> wrote:
> On 9/25/07, Stepan Mishura <st...@gmail.com> wrote:
> > On 9/25/07, Eugene Ostrovsky wrote:
> > > > Ops, I missed TPTP tests - 1 failure on Linux. Please pick up.
> > >
> > > TPTP Linux x86 - 1 test failed:
> > > org.eclipse.tptp.ac.testautomation.junits.AggStandaloneProfiling.agg_threadPowerWorkload_1_F
> > > We've seen this test failed before. It is a known intermittent failure
> > > due to TPTP bug.
> > >
> >
> > Yes, looks like intermittent failure - the test passed on two previous
> > snapshots (r577501 and r576550). I'm OK with excluding it if there are
> > no objections.
> >
>
> Well, I take back my words about two previous snapshots - it is not
> indication of intermittent failure. I can rerun TPTP suite and if the
> test pass then it can be excluded as intermittent failure otherwise
> the failure should be investigated. Agree?
> Thanks,
> Stepan.
>
> > I assume there should be corresponding JIRA filled if the TPTP bug is know.
> > Please update the JIRA with the patch that excludes the test.
> >
> > Thanks,
> > Stepan.
> >
> > > Probably it would be better to exclude this test.
> > >
> > > Thanks,
> > > Eugene.
> > >
> > >
> > > On 9/25/07, Stepan Mishura <st...@gmail.com> wrote:
> > > > On 9/25/07, Stepan Mishura <st...@gmail.com> wrote:
> > > > > On 9/24/07, Stepan Mishura <st...@gmail.com> wrote:
> > > > > > On 9/22/07, Stepan Mishura wrote:
> > > > > > > Hi,
> > > > > > >
> > > > > > > According to the plan - Sept. 22 is code freeze date for M3 so let's
> > > > > > > follow policy:
> > > > > > > "no more commits please without agreement from two committers on the dev list."
> > > > > > >
> > > > > > > Let's do more testing and analyze if there any critical/blocker issues
> > > > > > > for consideration.
> > > > > > > Please raise here issues that you think MUST be fixed for M3.
> > > > > >
> > > > > > Here is [1] the status of the last snapshot (r578410) that includes
> > > > > > last classlib updates. Unfortunately, not everything is green there.
> > > > > > I'm going to inspect all results to make sure that there are no
> > > > > > failures caused by CC configuration issues.
> > > > > >
> > > > >
> > > > > I've compared testing status for the last snapshot r578410 [1] with M2 [2][3].
> > > > >
> > > > > We have the following short status for failed suites:
> > > > >
> > > > > Windows_x86:
> > > > > * classlib: 2 tests from pack200 module fail on snapshot (but pass
> > > > > on debug build)
> > > > > * Eclipse unit tests 3.2: there is no tests report like for M3. The
> > > > > pass rate was improved from 99.32%[3] to 99.7%[1]
> > > > > * Eclipse unit tests 3.3 are new and the pass rate is 99.77%. I
> > > > > think is acceptable
> > > > > * EGA x48 hours scenario fails. According to [4] it passed on M2.
> > > > > * Functional: need more analysis, currently I see that 2 tests were
> > > > > enabled and new 15 regressions.
> > > > > * Geronimo: 2 regressions
> > > > > * JDK tools: 1 test failed. It might be intermediate failure - the
> > > > > test failed due to timeout
> > > > > * Reliability: 65 tests passed for M2 and 64 for M3. Investigation
> > > > > is required.
> > > > > * Stress: 190 tests passed for M2 and 189 for M3. Investigation is required.
> > > > >
> > > > > Linux_x86:
> > > > > * classlib: 2 tests from pack200 (as for Windows), 1 luni tests
> > > > > failed and 1 crash of security test
> > > > > * Eclipse unit tests 3.2: 2 suites crashed so pass rate is 69.60%. I
> > > > > assume this may be CC host configuration issue. Going to investigate.
> > > > > * Eclipse unit tests 3.3 are new and the pass rate is 96.47%. I
> > > > > think is acceptable
> > > > > * EGA x48 hours scenario: the same as for Windows (scenario fails on M3)
> > > > > * Functional: need more analysis, similar to Windows - some test are
> > > > > passing now but there are new failures.
> > > > > * Geronimo: 2 regressions (the same as for Windows)
> > > > > * Reliability: need more analysis
> > > > > * Stress: need more analysis
> > > > >
> > > >
> > > > Ops, I missed TPTP tests - 1 failure on Linux. Please pick up.
> > > >
> > > > > As I remember Sean took pack200 tests. And Alexei Zakharov took
> > > > > security test crash.
> > > > > I'm going to sort things out with Eclipse unit tests 3.2 crash on
> > > > > Linux. And to look info failed jdktools test.
> > > > >
> > > >
> > > > There are 2 JIRA for improving EUTs reports.
> > > > 1) HARMONY-4835: if fixes reporter to take into account expected crashes.
> > > > 2) HARMONY-4847: renames index.htm to index.html
> > > >
> > > > I'm going to apply patches them to the infra. Objections?
> > > >
> > > > Thanks,
> > > > Stepan.
> > > >
> > > > > So volunteers are required for: EGAx48, Geronimo, functional,
> > > > > reliability and stress suites.
> > > > >
> > > > > Also we have 2 JIRAs to be resolved for M3 under milstone unmblella[5]:
> > > > > https://issues.apache.org/jira/browse/HARMONY-4844
> > > > > https://issues.apache.org/jira/browse/HARMONY-4810
> > > > >
> > > > > [1] http://people.apache.org/~mloenko/snapshot_testing/script/r578410/index.html
> > > > > [2] http://people.apache.org/~mloenko/snapshot_testing/script/r551077/index.html
> > > > > [3] http://wiki.apache.org/harmony/milestones/M2
> > > > > [4] http://mail-archives.apache.org/mod_mbox/harmony-dev/200706.mbox/%3c678b3f320706290508l554079dau6af1a82b17d62b54@mail.gmail.com%3e
> > > > > [5] https://issues.apache.org/jira/browse/HARMONY-4843
> > > > >
> > > > > Thanks,
> > > > > Stepan.
> > > > >
> > > > >
> > > > > > Please feel free to pick up any issue for investigation. For example,
> > > > > > 2 pack200 classlib test failed. Also there is a crash of
> > > > > > org.apache.harmony.security.tests.java.security.cert.serialization.CertificateTest
> > > > > > on Linux x86
> > > > > >
> > > > > > BTW, should we consider BTI's workspace (that we use for M3 testing)
> > > > > > frozen too?
> > > > > >
> > > > > > [1] http://people.apache.org/~mloenko/snapshot_testing/script/r578410/index.html
> > > > > >
> > > > > > Thanks,
> > > > > > Stepan.
>
Re: [general] M3 - code frozen
Posted by Stepan Mishura <st...@gmail.com>.
On 9/25/07, Stepan Mishura <st...@gmail.com> wrote:
> On 9/25/07, Eugene Ostrovsky wrote:
> > > Ops, I missed TPTP tests - 1 failure on Linux. Please pick up.
> >
> > TPTP Linux x86 - 1 test failed:
> > org.eclipse.tptp.ac.testautomation.junits.AggStandaloneProfiling.agg_threadPowerWorkload_1_F
> > We've seen this test failed before. It is a known intermittent failure
> > due to TPTP bug.
> >
>
> Yes, looks like intermittent failure - the test passed on two previous
> snapshots (r577501 and r576550). I'm OK with excluding it if there are
> no objections.
>
Well, I take back my words about two previous snapshots - it is not
indication of intermittent failure. I can rerun TPTP suite and if the
test pass then it can be excluded as intermittent failure otherwise
the failure should be investigated. Agree?
Thanks,
Stepan.
> I assume there should be corresponding JIRA filled if the TPTP bug is know.
> Please update the JIRA with the patch that excludes the test.
>
> Thanks,
> Stepan.
>
> > Probably it would be better to exclude this test.
> >
> > Thanks,
> > Eugene.
> >
> >
> > On 9/25/07, Stepan Mishura <st...@gmail.com> wrote:
> > > On 9/25/07, Stepan Mishura <st...@gmail.com> wrote:
> > > > On 9/24/07, Stepan Mishura <st...@gmail.com> wrote:
> > > > > On 9/22/07, Stepan Mishura wrote:
> > > > > > Hi,
> > > > > >
> > > > > > According to the plan - Sept. 22 is code freeze date for M3 so let's
> > > > > > follow policy:
> > > > > > "no more commits please without agreement from two committers on the dev list."
> > > > > >
> > > > > > Let's do more testing and analyze if there any critical/blocker issues
> > > > > > for consideration.
> > > > > > Please raise here issues that you think MUST be fixed for M3.
> > > > >
> > > > > Here is [1] the status of the last snapshot (r578410) that includes
> > > > > last classlib updates. Unfortunately, not everything is green there.
> > > > > I'm going to inspect all results to make sure that there are no
> > > > > failures caused by CC configuration issues.
> > > > >
> > > >
> > > > I've compared testing status for the last snapshot r578410 [1] with M2 [2][3].
> > > >
> > > > We have the following short status for failed suites:
> > > >
> > > > Windows_x86:
> > > > * classlib: 2 tests from pack200 module fail on snapshot (but pass
> > > > on debug build)
> > > > * Eclipse unit tests 3.2: there is no tests report like for M3. The
> > > > pass rate was improved from 99.32%[3] to 99.7%[1]
> > > > * Eclipse unit tests 3.3 are new and the pass rate is 99.77%. I
> > > > think is acceptable
> > > > * EGA x48 hours scenario fails. According to [4] it passed on M2.
> > > > * Functional: need more analysis, currently I see that 2 tests were
> > > > enabled and new 15 regressions.
> > > > * Geronimo: 2 regressions
> > > > * JDK tools: 1 test failed. It might be intermediate failure - the
> > > > test failed due to timeout
> > > > * Reliability: 65 tests passed for M2 and 64 for M3. Investigation
> > > > is required.
> > > > * Stress: 190 tests passed for M2 and 189 for M3. Investigation is required.
> > > >
> > > > Linux_x86:
> > > > * classlib: 2 tests from pack200 (as for Windows), 1 luni tests
> > > > failed and 1 crash of security test
> > > > * Eclipse unit tests 3.2: 2 suites crashed so pass rate is 69.60%. I
> > > > assume this may be CC host configuration issue. Going to investigate.
> > > > * Eclipse unit tests 3.3 are new and the pass rate is 96.47%. I
> > > > think is acceptable
> > > > * EGA x48 hours scenario: the same as for Windows (scenario fails on M3)
> > > > * Functional: need more analysis, similar to Windows - some test are
> > > > passing now but there are new failures.
> > > > * Geronimo: 2 regressions (the same as for Windows)
> > > > * Reliability: need more analysis
> > > > * Stress: need more analysis
> > > >
> > >
> > > Ops, I missed TPTP tests - 1 failure on Linux. Please pick up.
> > >
> > > > As I remember Sean took pack200 tests. And Alexei Zakharov took
> > > > security test crash.
> > > > I'm going to sort things out with Eclipse unit tests 3.2 crash on
> > > > Linux. And to look info failed jdktools test.
> > > >
> > >
> > > There are 2 JIRA for improving EUTs reports.
> > > 1) HARMONY-4835: if fixes reporter to take into account expected crashes.
> > > 2) HARMONY-4847: renames index.htm to index.html
> > >
> > > I'm going to apply patches them to the infra. Objections?
> > >
> > > Thanks,
> > > Stepan.
> > >
> > > > So volunteers are required for: EGAx48, Geronimo, functional,
> > > > reliability and stress suites.
> > > >
> > > > Also we have 2 JIRAs to be resolved for M3 under milstone unmblella[5]:
> > > > https://issues.apache.org/jira/browse/HARMONY-4844
> > > > https://issues.apache.org/jira/browse/HARMONY-4810
> > > >
> > > > [1] http://people.apache.org/~mloenko/snapshot_testing/script/r578410/index.html
> > > > [2] http://people.apache.org/~mloenko/snapshot_testing/script/r551077/index.html
> > > > [3] http://wiki.apache.org/harmony/milestones/M2
> > > > [4] http://mail-archives.apache.org/mod_mbox/harmony-dev/200706.mbox/%3c678b3f320706290508l554079dau6af1a82b17d62b54@mail.gmail.com%3e
> > > > [5] https://issues.apache.org/jira/browse/HARMONY-4843
> > > >
> > > > Thanks,
> > > > Stepan.
> > > >
> > > >
> > > > > Please feel free to pick up any issue for investigation. For example,
> > > > > 2 pack200 classlib test failed. Also there is a crash of
> > > > > org.apache.harmony.security.tests.java.security.cert.serialization.CertificateTest
> > > > > on Linux x86
> > > > >
> > > > > BTW, should we consider BTI's workspace (that we use for M3 testing)
> > > > > frozen too?
> > > > >
> > > > > [1] http://people.apache.org/~mloenko/snapshot_testing/script/r578410/index.html
> > > > >
> > > > > Thanks,
> > > > > Stepan.
Re: [general] M3 - code frozen
Posted by Stepan Mishura <st...@gmail.com>.
On 9/25/07, Eugene Ostrovsky wrote:
> > Ops, I missed TPTP tests - 1 failure on Linux. Please pick up.
>
> TPTP Linux x86 - 1 test failed:
> org.eclipse.tptp.ac.testautomation.junits.AggStandaloneProfiling.agg_threadPowerWorkload_1_F
> We've seen this test failed before. It is a known intermittent failure
> due to TPTP bug.
>
Yes, looks like intermittent failure - the test passed on two previous
snapshots (r577501 and r576550). I'm OK with excluding it if there are
no objections.
I assume there should be corresponding JIRA filled if the TPTP bug is know.
Please update the JIRA with the patch that excludes the test.
Thanks,
Stepan.
> Probably it would be better to exclude this test.
>
> Thanks,
> Eugene.
>
>
> On 9/25/07, Stepan Mishura <st...@gmail.com> wrote:
> > On 9/25/07, Stepan Mishura <st...@gmail.com> wrote:
> > > On 9/24/07, Stepan Mishura <st...@gmail.com> wrote:
> > > > On 9/22/07, Stepan Mishura wrote:
> > > > > Hi,
> > > > >
> > > > > According to the plan - Sept. 22 is code freeze date for M3 so let's
> > > > > follow policy:
> > > > > "no more commits please without agreement from two committers on the dev list."
> > > > >
> > > > > Let's do more testing and analyze if there any critical/blocker issues
> > > > > for consideration.
> > > > > Please raise here issues that you think MUST be fixed for M3.
> > > >
> > > > Here is [1] the status of the last snapshot (r578410) that includes
> > > > last classlib updates. Unfortunately, not everything is green there.
> > > > I'm going to inspect all results to make sure that there are no
> > > > failures caused by CC configuration issues.
> > > >
> > >
> > > I've compared testing status for the last snapshot r578410 [1] with M2 [2][3].
> > >
> > > We have the following short status for failed suites:
> > >
> > > Windows_x86:
> > > * classlib: 2 tests from pack200 module fail on snapshot (but pass
> > > on debug build)
> > > * Eclipse unit tests 3.2: there is no tests report like for M3. The
> > > pass rate was improved from 99.32%[3] to 99.7%[1]
> > > * Eclipse unit tests 3.3 are new and the pass rate is 99.77%. I
> > > think is acceptable
> > > * EGA x48 hours scenario fails. According to [4] it passed on M2.
> > > * Functional: need more analysis, currently I see that 2 tests were
> > > enabled and new 15 regressions.
> > > * Geronimo: 2 regressions
> > > * JDK tools: 1 test failed. It might be intermediate failure - the
> > > test failed due to timeout
> > > * Reliability: 65 tests passed for M2 and 64 for M3. Investigation
> > > is required.
> > > * Stress: 190 tests passed for M2 and 189 for M3. Investigation is required.
> > >
> > > Linux_x86:
> > > * classlib: 2 tests from pack200 (as for Windows), 1 luni tests
> > > failed and 1 crash of security test
> > > * Eclipse unit tests 3.2: 2 suites crashed so pass rate is 69.60%. I
> > > assume this may be CC host configuration issue. Going to investigate.
> > > * Eclipse unit tests 3.3 are new and the pass rate is 96.47%. I
> > > think is acceptable
> > > * EGA x48 hours scenario: the same as for Windows (scenario fails on M3)
> > > * Functional: need more analysis, similar to Windows - some test are
> > > passing now but there are new failures.
> > > * Geronimo: 2 regressions (the same as for Windows)
> > > * Reliability: need more analysis
> > > * Stress: need more analysis
> > >
> >
> > Ops, I missed TPTP tests - 1 failure on Linux. Please pick up.
> >
> > > As I remember Sean took pack200 tests. And Alexei Zakharov took
> > > security test crash.
> > > I'm going to sort things out with Eclipse unit tests 3.2 crash on
> > > Linux. And to look info failed jdktools test.
> > >
> >
> > There are 2 JIRA for improving EUTs reports.
> > 1) HARMONY-4835: if fixes reporter to take into account expected crashes.
> > 2) HARMONY-4847: renames index.htm to index.html
> >
> > I'm going to apply patches them to the infra. Objections?
> >
> > Thanks,
> > Stepan.
> >
> > > So volunteers are required for: EGAx48, Geronimo, functional,
> > > reliability and stress suites.
> > >
> > > Also we have 2 JIRAs to be resolved for M3 under milstone unmblella[5]:
> > > https://issues.apache.org/jira/browse/HARMONY-4844
> > > https://issues.apache.org/jira/browse/HARMONY-4810
> > >
> > > [1] http://people.apache.org/~mloenko/snapshot_testing/script/r578410/index.html
> > > [2] http://people.apache.org/~mloenko/snapshot_testing/script/r551077/index.html
> > > [3] http://wiki.apache.org/harmony/milestones/M2
> > > [4] http://mail-archives.apache.org/mod_mbox/harmony-dev/200706.mbox/%3c678b3f320706290508l554079dau6af1a82b17d62b54@mail.gmail.com%3e
> > > [5] https://issues.apache.org/jira/browse/HARMONY-4843
> > >
> > > Thanks,
> > > Stepan.
> > >
> > >
> > > > Please feel free to pick up any issue for investigation. For example,
> > > > 2 pack200 classlib test failed. Also there is a crash of
> > > > org.apache.harmony.security.tests.java.security.cert.serialization.CertificateTest
> > > > on Linux x86
> > > >
> > > > BTW, should we consider BTI's workspace (that we use for M3 testing)
> > > > frozen too?
> > > >
> > > > [1] http://people.apache.org/~mloenko/snapshot_testing/script/r578410/index.html
> > > >
> > > > Thanks,
> > > > Stepan.
Re: [general] M3 - code frozen
Posted by Eugene Ostrovsky <eu...@gmail.com>.
> Ops, I missed TPTP tests - 1 failure on Linux. Please pick up.
TPTP Linux x86 - 1 test failed:
org.eclipse.tptp.ac.testautomation.junits.AggStandaloneProfiling.agg_threadPowerWorkload_1_F
We've seen this test failed before. It is a known intermittent failure
due to TPTP bug.
Probably it would be better to exclude this test.
Thanks,
Eugene.
On 9/25/07, Stepan Mishura <st...@gmail.com> wrote:
> On 9/25/07, Stepan Mishura <st...@gmail.com> wrote:
> > On 9/24/07, Stepan Mishura <st...@gmail.com> wrote:
> > > On 9/22/07, Stepan Mishura wrote:
> > > > Hi,
> > > >
> > > > According to the plan - Sept. 22 is code freeze date for M3 so let's
> > > > follow policy:
> > > > "no more commits please without agreement from two committers on the dev list."
> > > >
> > > > Let's do more testing and analyze if there any critical/blocker issues
> > > > for consideration.
> > > > Please raise here issues that you think MUST be fixed for M3.
> > >
> > > Here is [1] the status of the last snapshot (r578410) that includes
> > > last classlib updates. Unfortunately, not everything is green there.
> > > I'm going to inspect all results to make sure that there are no
> > > failures caused by CC configuration issues.
> > >
> >
> > I've compared testing status for the last snapshot r578410 [1] with M2 [2][3].
> >
> > We have the following short status for failed suites:
> >
> > Windows_x86:
> > * classlib: 2 tests from pack200 module fail on snapshot (but pass
> > on debug build)
> > * Eclipse unit tests 3.2: there is no tests report like for M3. The
> > pass rate was improved from 99.32%[3] to 99.7%[1]
> > * Eclipse unit tests 3.3 are new and the pass rate is 99.77%. I
> > think is acceptable
> > * EGA x48 hours scenario fails. According to [4] it passed on M2.
> > * Functional: need more analysis, currently I see that 2 tests were
> > enabled and new 15 regressions.
> > * Geronimo: 2 regressions
> > * JDK tools: 1 test failed. It might be intermediate failure - the
> > test failed due to timeout
> > * Reliability: 65 tests passed for M2 and 64 for M3. Investigation
> > is required.
> > * Stress: 190 tests passed for M2 and 189 for M3. Investigation is required.
> >
> > Linux_x86:
> > * classlib: 2 tests from pack200 (as for Windows), 1 luni tests
> > failed and 1 crash of security test
> > * Eclipse unit tests 3.2: 2 suites crashed so pass rate is 69.60%. I
> > assume this may be CC host configuration issue. Going to investigate.
> > * Eclipse unit tests 3.3 are new and the pass rate is 96.47%. I
> > think is acceptable
> > * EGA x48 hours scenario: the same as for Windows (scenario fails on M3)
> > * Functional: need more analysis, similar to Windows - some test are
> > passing now but there are new failures.
> > * Geronimo: 2 regressions (the same as for Windows)
> > * Reliability: need more analysis
> > * Stress: need more analysis
> >
>
> Ops, I missed TPTP tests - 1 failure on Linux. Please pick up.
>
> > As I remember Sean took pack200 tests. And Alexei Zakharov took
> > security test crash.
> > I'm going to sort things out with Eclipse unit tests 3.2 crash on
> > Linux. And to look info failed jdktools test.
> >
>
> There are 2 JIRA for improving EUTs reports.
> 1) HARMONY-4835: if fixes reporter to take into account expected crashes.
> 2) HARMONY-4847: renames index.htm to index.html
>
> I'm going to apply patches them to the infra. Objections?
>
> Thanks,
> Stepan.
>
> > So volunteers are required for: EGAx48, Geronimo, functional,
> > reliability and stress suites.
> >
> > Also we have 2 JIRAs to be resolved for M3 under milstone unmblella[5]:
> > https://issues.apache.org/jira/browse/HARMONY-4844
> > https://issues.apache.org/jira/browse/HARMONY-4810
> >
> > [1] http://people.apache.org/~mloenko/snapshot_testing/script/r578410/index.html
> > [2] http://people.apache.org/~mloenko/snapshot_testing/script/r551077/index.html
> > [3] http://wiki.apache.org/harmony/milestones/M2
> > [4] http://mail-archives.apache.org/mod_mbox/harmony-dev/200706.mbox/%3c678b3f320706290508l554079dau6af1a82b17d62b54@mail.gmail.com%3e
> > [5] https://issues.apache.org/jira/browse/HARMONY-4843
> >
> > Thanks,
> > Stepan.
> >
> >
> > > Please feel free to pick up any issue for investigation. For example,
> > > 2 pack200 classlib test failed. Also there is a crash of
> > > org.apache.harmony.security.tests.java.security.cert.serialization.CertificateTest
> > > on Linux x86
> > >
> > > BTW, should we consider BTI's workspace (that we use for M3 testing)
> > > frozen too?
> > >
> > > [1] http://people.apache.org/~mloenko/snapshot_testing/script/r578410/index.html
> > >
> > > Thanks,
> > > Stepan.
> >
>
Re: [general] M3 - code frozen
Posted by Stepan Mishura <st...@gmail.com>.
On 9/25/07, Stepan Mishura <st...@gmail.com> wrote:
> On 9/24/07, Stepan Mishura <st...@gmail.com> wrote:
> > On 9/22/07, Stepan Mishura wrote:
> > > Hi,
> > >
> > > According to the plan - Sept. 22 is code freeze date for M3 so let's
> > > follow policy:
> > > "no more commits please without agreement from two committers on the dev list."
> > >
> > > Let's do more testing and analyze if there any critical/blocker issues
> > > for consideration.
> > > Please raise here issues that you think MUST be fixed for M3.
> >
> > Here is [1] the status of the last snapshot (r578410) that includes
> > last classlib updates. Unfortunately, not everything is green there.
> > I'm going to inspect all results to make sure that there are no
> > failures caused by CC configuration issues.
> >
>
> I've compared testing status for the last snapshot r578410 [1] with M2 [2][3].
>
> We have the following short status for failed suites:
>
> Windows_x86:
> * classlib: 2 tests from pack200 module fail on snapshot (but pass
> on debug build)
> * Eclipse unit tests 3.2: there is no tests report like for M3. The
> pass rate was improved from 99.32%[3] to 99.7%[1]
> * Eclipse unit tests 3.3 are new and the pass rate is 99.77%. I
> think is acceptable
> * EGA x48 hours scenario fails. According to [4] it passed on M2.
> * Functional: need more analysis, currently I see that 2 tests were
> enabled and new 15 regressions.
> * Geronimo: 2 regressions
> * JDK tools: 1 test failed. It might be intermediate failure - the
> test failed due to timeout
> * Reliability: 65 tests passed for M2 and 64 for M3. Investigation
> is required.
> * Stress: 190 tests passed for M2 and 189 for M3. Investigation is required.
>
> Linux_x86:
> * classlib: 2 tests from pack200 (as for Windows), 1 luni tests
> failed and 1 crash of security test
> * Eclipse unit tests 3.2: 2 suites crashed so pass rate is 69.60%. I
> assume this may be CC host configuration issue. Going to investigate.
> * Eclipse unit tests 3.3 are new and the pass rate is 96.47%. I
> think is acceptable
> * EGA x48 hours scenario: the same as for Windows (scenario fails on M3)
> * Functional: need more analysis, similar to Windows - some test are
> passing now but there are new failures.
> * Geronimo: 2 regressions (the same as for Windows)
> * Reliability: need more analysis
> * Stress: need more analysis
>
Ops, I missed TPTP tests - 1 failure on Linux. Please pick up.
> As I remember Sean took pack200 tests. And Alexei Zakharov took
> security test crash.
> I'm going to sort things out with Eclipse unit tests 3.2 crash on
> Linux. And to look info failed jdktools test.
>
There are 2 JIRA for improving EUTs reports.
1) HARMONY-4835: if fixes reporter to take into account expected crashes.
2) HARMONY-4847: renames index.htm to index.html
I'm going to apply patches them to the infra. Objections?
Thanks,
Stepan.
> So volunteers are required for: EGAx48, Geronimo, functional,
> reliability and stress suites.
>
> Also we have 2 JIRAs to be resolved for M3 under milstone unmblella[5]:
> https://issues.apache.org/jira/browse/HARMONY-4844
> https://issues.apache.org/jira/browse/HARMONY-4810
>
> [1] http://people.apache.org/~mloenko/snapshot_testing/script/r578410/index.html
> [2] http://people.apache.org/~mloenko/snapshot_testing/script/r551077/index.html
> [3] http://wiki.apache.org/harmony/milestones/M2
> [4] http://mail-archives.apache.org/mod_mbox/harmony-dev/200706.mbox/%3c678b3f320706290508l554079dau6af1a82b17d62b54@mail.gmail.com%3e
> [5] https://issues.apache.org/jira/browse/HARMONY-4843
>
> Thanks,
> Stepan.
>
>
> > Please feel free to pick up any issue for investigation. For example,
> > 2 pack200 classlib test failed. Also there is a crash of
> > org.apache.harmony.security.tests.java.security.cert.serialization.CertificateTest
> > on Linux x86
> >
> > BTW, should we consider BTI's workspace (that we use for M3 testing)
> > frozen too?
> >
> > [1] http://people.apache.org/~mloenko/snapshot_testing/script/r578410/index.html
> >
> > Thanks,
> > Stepan.
>
Re: [general] M3 - code frozen
Posted by Stepan Mishura <st...@gmail.com>.
On 9/24/07, Stepan Mishura <st...@gmail.com> wrote:
> On 9/22/07, Stepan Mishura wrote:
> > Hi,
> >
> > According to the plan - Sept. 22 is code freeze date for M3 so let's
> > follow policy:
> > "no more commits please without agreement from two committers on the dev list."
> >
> > Let's do more testing and analyze if there any critical/blocker issues
> > for consideration.
> > Please raise here issues that you think MUST be fixed for M3.
>
> Here is [1] the status of the last snapshot (r578410) that includes
> last classlib updates. Unfortunately, not everything is green there.
> I'm going to inspect all results to make sure that there are no
> failures caused by CC configuration issues.
>
I've compared testing status for the last snapshot r578410 [1] with M2 [2][3].
We have the following short status for failed suites:
Windows_x86:
* classlib: 2 tests from pack200 module fail on snapshot (but pass
on debug build)
* Eclipse unit tests 3.2: there is no tests report like for M3. The
pass rate was improved from 99.32%[3] to 99.7%[1]
* Eclipse unit tests 3.3 are new and the pass rate is 99.77%. I
think is acceptable
* EGA x48 hours scenario fails. According to [4] it passed on M2.
* Functional: need more analysis, currently I see that 2 tests were
enabled and new 15 regressions.
* Geronimo: 2 regressions
* JDK tools: 1 test failed. It might be intermediate failure - the
test failed due to timeout
* Reliability: 65 tests passed for M2 and 64 for M3. Investigation
is required.
* Stress: 190 tests passed for M2 and 189 for M3. Investigation is required.
Linux_x86:
* classlib: 2 tests from pack200 (as for Windows), 1 luni tests
failed and 1 crash of security test
* Eclipse unit tests 3.2: 2 suites crashed so pass rate is 69.60%. I
assume this may be CC host configuration issue. Going to investigate.
* Eclipse unit tests 3.3 are new and the pass rate is 96.47%. I
think is acceptable
* EGA x48 hours scenario: the same as for Windows (scenario fails on M3)
* Functional: need more analysis, similar to Windows - some test are
passing now but there are new failures.
* Geronimo: 2 regressions (the same as for Windows)
* Reliability: need more analysis
* Stress: need more analysis
As I remember Sean took pack200 tests. And Alexei Zakharov took
security test crash.
I'm going to sort things out with Eclipse unit tests 3.2 crash on
Linux. And to look info failed jdktools test.
So volunteers are required for: EGAx48, Geronimo, functional,
reliability and stress suites.
Also we have 2 JIRAs to be resolved for M3 under milstone unmblella[5]:
https://issues.apache.org/jira/browse/HARMONY-4844
https://issues.apache.org/jira/browse/HARMONY-4810
[1] http://people.apache.org/~mloenko/snapshot_testing/script/r578410/index.html
[2] http://people.apache.org/~mloenko/snapshot_testing/script/r551077/index.html
[3] http://wiki.apache.org/harmony/milestones/M2
[4] http://mail-archives.apache.org/mod_mbox/harmony-dev/200706.mbox/%3c678b3f320706290508l554079dau6af1a82b17d62b54@mail.gmail.com%3e
[5] https://issues.apache.org/jira/browse/HARMONY-4843
Thanks,
Stepan.
> Please feel free to pick up any issue for investigation. For example,
> 2 pack200 classlib test failed. Also there is a crash of
> org.apache.harmony.security.tests.java.security.cert.serialization.CertificateTest
> on Linux x86
>
> BTW, should we consider BTI's workspace (that we use for M3 testing)
> frozen too?
>
> [1] http://people.apache.org/~mloenko/snapshot_testing/script/r578410/index.html
>
> Thanks,
> Stepan.
Re: [general] M3 - code frozen
Posted by Alexey Varlamov <al...@gmail.com>.
2007/9/24, Stepan Mishura <st...@gmail.com>:
> On 9/22/07, Stepan Mishura wrote:
> > Hi,
> >
> > According to the plan - Sept. 22 is code freeze date for M3 so let's
> > follow policy:
> > "no more commits please without agreement from two committers on the dev list."
> >
> > Let's do more testing and analyze if there any critical/blocker issues
> > for consideration.
> > Please raise here issues that you think MUST be fixed for M3.
>
> Here is [1] the status of the last snapshot (r578410) that includes
> last classlib updates. Unfortunately, not everything is green there.
> I'm going to inspect all results to make sure that there are no
> failures caused by CC configuration issues.
>
> Please feel free to pick up any issue for investigation. For example,
> 2 pack200 classlib test failed. Also there is a crash of
> org.apache.harmony.security.tests.java.security.cert.serialization.CertificateTest
> on Linux x86
>
> BTW, should we consider BTI's workspace (that we use for M3 testing)
> frozen too?
Yes, this makes sense. Let's allow in critical patches only as agreed
by 2 committers here. Well, at least for the framework and existing
adaptors - see no harm to add new adaptors.
>
> [1] http://people.apache.org/~mloenko/snapshot_testing/script/r578410/index.html
>
> Thanks,
> Stepan.
>
Re: [general] M3 - code frozen
Posted by Alexei Zakharov <al...@gmail.com>.
>Also there is a crash of
> org.apache.harmony.security.tests.java.security.cert.serialization.CertificateTest
> on Linux x86
I can reproduce this crash too. Moreover, the another test from
security module hangs then I run it both on Linux and Windows:
org.apache.harmony.security.tests.asn1.der.DerUTCTimeEDTest
Thanks,
Alexei
2007/9/24, Stepan Mishura <st...@gmail.com>:
> On 9/22/07, Stepan Mishura wrote:
> > Hi,
> >
> > According to the plan - Sept. 22 is code freeze date for M3 so let's
> > follow policy:
> > "no more commits please without agreement from two committers on the dev list."
> >
> > Let's do more testing and analyze if there any critical/blocker issues
> > for consideration.
> > Please raise here issues that you think MUST be fixed for M3.
>
> Here is [1] the status of the last snapshot (r578410) that includes
> last classlib updates. Unfortunately, not everything is green there.
> I'm going to inspect all results to make sure that there are no
> failures caused by CC configuration issues.
>
> Please feel free to pick up any issue for investigation. For example,
> 2 pack200 classlib test failed. Also there is a crash of
> org.apache.harmony.security.tests.java.security.cert.serialization.CertificateTest
> on Linux x86
>
> BTW, should we consider BTI's workspace (that we use for M3 testing)
> frozen too?
>
> [1] http://people.apache.org/~mloenko/snapshot_testing/script/r578410/index.html
>
> Thanks,
> Stepan.
Re: [general] M3 - code frozen
Posted by Sian January <si...@googlemail.com>.
I will take a look at the pack200 tests. They all pass on my local machine
so it will need some investigation, but I don't think this is necessarily a
blocking issue for M3 because pack200 is still a work in progress.
Thanks,
Sian
On 24/09/2007, Stepan Mishura <st...@gmail.com> wrote:
>
> On 9/22/07, Stepan Mishura wrote:
> > Hi,
> >
> > According to the plan - Sept. 22 is code freeze date for M3 so let's
> > follow policy:
> > "no more commits please without agreement from two committers on the dev
> list."
> >
> > Let's do more testing and analyze if there any critical/blocker issues
> > for consideration.
> > Please raise here issues that you think MUST be fixed for M3.
>
> Here is [1] the status of the last snapshot (r578410) that includes
> last classlib updates. Unfortunately, not everything is green there.
> I'm going to inspect all results to make sure that there are no
> failures caused by CC configuration issues.
>
> Please feel free to pick up any issue for investigation. For example,
> 2 pack200 classlib test failed. Also there is a crash of
>
> org.apache.harmony.security.tests.java.security.cert.serialization.CertificateTest
> on Linux x86
>
> BTW, should we consider BTI's workspace (that we use for M3 testing)
> frozen too?
>
> [1]
> http://people.apache.org/~mloenko/snapshot_testing/script/r578410/index.html
>
> Thanks,
> Stepan.
>
--
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Re: [general] M3 - code frozen
Posted by Stepan Mishura <st...@gmail.com>.
On 9/22/07, Stepan Mishura wrote:
> Hi,
>
> According to the plan - Sept. 22 is code freeze date for M3 so let's
> follow policy:
> "no more commits please without agreement from two committers on the dev list."
>
> Let's do more testing and analyze if there any critical/blocker issues
> for consideration.
> Please raise here issues that you think MUST be fixed for M3.
Here is [1] the status of the last snapshot (r578410) that includes
last classlib updates. Unfortunately, not everything is green there.
I'm going to inspect all results to make sure that there are no
failures caused by CC configuration issues.
Please feel free to pick up any issue for investigation. For example,
2 pack200 classlib test failed. Also there is a crash of
org.apache.harmony.security.tests.java.security.cert.serialization.CertificateTest
on Linux x86
BTW, should we consider BTI's workspace (that we use for M3 testing)
frozen too?
[1] http://people.apache.org/~mloenko/snapshot_testing/script/r578410/index.html
Thanks,
Stepan.
Re: [general] M3 - code frozen
Posted by Stepan Mishura <st...@gmail.com>.
On 10/1/07, Alexey Varlamov <al...@gmail.com> wrote:
> 2007/10/1, Stepan Mishura <st...@gmail.com>:
> > Hi all,
> >
> > There are several fixes to be included to M3 release so I'm going to
> > launch today next snapshot building and testing. Please let me know if
> > you know not committed updates/fixes for the next release candidate.
>
> Please consider applying the quickfix for (HARMONY-4184)
> [classlib][security]DefaultPolicy fails to grant Permissions according
> to policy file to classes in extension directory. It might be a
> blocker for some security-related scenarious.
>
+1 for commiting.
-Stepan.
>
> >
> > Thanks,
> > Stepan.
> >
> > On 9/22/07, Stepan Mishura wrote:
> > > Hi,
> > >
> > > According to the plan - Sept. 22 is code freeze date for M3 so let's
> > > follow policy:
> > > "no more commits please without agreement from two committers on the dev list."
> > >
> > > Let's do more testing and analyze if there any critical/blocker issues
> > > for consideration.
> > > Please raise here issues that you think MUST be fixed for M3.
> > >
> > > Thanks,
> > > Stepan Mishura
> > > Intel Enterprise Solutions Software Division
Re: [general] M3 - code frozen
Posted by Alexey Varlamov <al...@gmail.com>.
2007/10/1, Stepan Mishura <st...@gmail.com>:
> Hi all,
>
> There are several fixes to be included to M3 release so I'm going to
> launch today next snapshot building and testing. Please let me know if
> you know not committed updates/fixes for the next release candidate.
Please consider applying the quickfix for (HARMONY-4184)
[classlib][security]DefaultPolicy fails to grant Permissions according
to policy file to classes in extension directory. It might be a
blocker for some security-related scenarious.
>
> Thanks,
> Stepan.
>
> On 9/22/07, Stepan Mishura wrote:
> > Hi,
> >
> > According to the plan - Sept. 22 is code freeze date for M3 so let's
> > follow policy:
> > "no more commits please without agreement from two committers on the dev list."
> >
> > Let's do more testing and analyze if there any critical/blocker issues
> > for consideration.
> > Please raise here issues that you think MUST be fixed for M3.
> >
> > Thanks,
> > Stepan Mishura
> > Intel Enterprise Solutions Software Division
> >
>
Re: [general] M3 - code frozen
Posted by Stepan Mishura <st...@gmail.com>.
Hi all,
There are several fixes to be included to M3 release so I'm going to
launch today next snapshot building and testing. Please let me know if
you know not committed updates/fixes for the next release candidate.
Thanks,
Stepan.
On 9/22/07, Stepan Mishura wrote:
> Hi,
>
> According to the plan - Sept. 22 is code freeze date for M3 so let's
> follow policy:
> "no more commits please without agreement from two committers on the dev list."
>
> Let's do more testing and analyze if there any critical/blocker issues
> for consideration.
> Please raise here issues that you think MUST be fixed for M3.
>
> Thanks,
> Stepan Mishura
> Intel Enterprise Solutions Software Division
>
Re: [general] M3 - code frozen
Posted by Alexey Varlamov <al...@gmail.com>.
Added link to HARMONY-4844 [build] Wrong hythr.lib copied to federated build,
it blocks snapshot testing.
2007/9/24, Stepan Mishura <st...@gmail.com>:
> On 9/24/07, Stepan Mishura wrote:
> > On 9/23/07, Tim Ellison wrote:
> > > Stepan Mishura wrote:
> > > > According to the plan - Sept. 22 is code freeze date for M3 so let's
> > > > follow policy:
> > > > "no more commits please without agreement from two committers on the dev list."
> > > >
> > > > Let's do more testing and analyze if there any critical/blocker issues
> > > > for consideration.
> > > > Please raise here issues that you think MUST be fixed for M3.
> > >
> > > Agreed, thanks for the reminder. The focus moves onto testing what we
> > > have got, and raising any regressions or bugs that seriously inhibit
> > > areas of functionality. The goal is a stable build at the end of the month.
> > >
> > > A MUST fix is removing the IDEA algorithm from the version of
> > > BouncyCastle that we redistribute -- see HARMONY-4810.
> > >
> > > Shall we track these with an umbrella JIRA issue?
> > >
> >
> > Yes, it makes sense to create umbrella JIRA to track what should be done for M3.
> >
>
> I've created:
> https://issues.apache.org/jira/browse/HARMONY-4843
>
> -Stepan.
>
> >
> > > As part of the code freeze, I'm going to resync the Java 6 branch.
> > >
> > > Regards,
> > > Tim
>
Re: [general] M3 - code frozen
Posted by Stepan Mishura <st...@gmail.com>.
On 9/24/07, Stepan Mishura wrote:
> On 9/23/07, Tim Ellison wrote:
> > Stepan Mishura wrote:
> > > According to the plan - Sept. 22 is code freeze date for M3 so let's
> > > follow policy:
> > > "no more commits please without agreement from two committers on the dev list."
> > >
> > > Let's do more testing and analyze if there any critical/blocker issues
> > > for consideration.
> > > Please raise here issues that you think MUST be fixed for M3.
> >
> > Agreed, thanks for the reminder. The focus moves onto testing what we
> > have got, and raising any regressions or bugs that seriously inhibit
> > areas of functionality. The goal is a stable build at the end of the month.
> >
> > A MUST fix is removing the IDEA algorithm from the version of
> > BouncyCastle that we redistribute -- see HARMONY-4810.
> >
> > Shall we track these with an umbrella JIRA issue?
> >
>
> Yes, it makes sense to create umbrella JIRA to track what should be done for M3.
>
I've created:
https://issues.apache.org/jira/browse/HARMONY-4843
-Stepan.
>
> > As part of the code freeze, I'm going to resync the Java 6 branch.
> >
> > Regards,
> > Tim
Re: [general] M3 - code frozen
Posted by Stepan Mishura <st...@gmail.com>.
On 9/23/07, Tim Ellison wrote:
> Stepan Mishura wrote:
> > According to the plan - Sept. 22 is code freeze date for M3 so let's
> > follow policy:
> > "no more commits please without agreement from two committers on the dev list."
> >
> > Let's do more testing and analyze if there any critical/blocker issues
> > for consideration.
> > Please raise here issues that you think MUST be fixed for M3.
>
> Agreed, thanks for the reminder. The focus moves onto testing what we
> have got, and raising any regressions or bugs that seriously inhibit
> areas of functionality. The goal is a stable build at the end of the month.
>
> A MUST fix is removing the IDEA algorithm from the version of
> BouncyCastle that we redistribute -- see HARMONY-4810.
>
> Shall we track these with an umbrella JIRA issue?
>
Yes, it makes sense to create umbrella JIRA to track what should be done for M3.
-Stepan.
> As part of the code freeze, I'm going to resync the Java 6 branch.
>
> Regards,
> Tim
>
Re: [general] M3 - code frozen
Posted by Tim Ellison <t....@gmail.com>.
Mark Hindess wrote:
> On 24 September 2007 at 11:46, Mark Hindess <ma...@googlemail.com> wrote:
>> Maybe we should just replace the IDEAEngine.class with a dummy class
>> that generates not implemented exceptions and reports how to get the
>> real version.
>
> Looks like someone else had a similar idea (pun intended, sorry ;-):
>
> https://issues.apache.org/jira/browse/GERONIMO-880
Makes sense to me as the least intrusive change, and an opportunity to
inform users about how to get the IDEA algorithm if they want to use it.
Regards,
Tim
Re: [general] M3 - code frozen
Posted by Mark Hindess <ma...@googlemail.com>.
On 24 September 2007 at 11:46, Mark Hindess <ma...@googlemail.com> wrote:
>
> Maybe we should just replace the IDEAEngine.class with a dummy class
> that generates not implemented exceptions and reports how to get the
> real version.
Looks like someone else had a similar idea (pun intended, sorry ;-):
https://issues.apache.org/jira/browse/GERONIMO-880
-Mark.
>
> On 24 September 2007 at 17:31, "Mikhail Loenko" <ml...@gmail.com> wrote:
> > 2007/9/23, Tim Ellison <t....@gmail.com>:
> > > Stepan Mishura wrote:
> > > > According to the plan - Sept. 22 is code freeze date for M3 so let's
> > > > follow policy:
> > > > "no more commits please without agreement from two committers on the de
> v
> > list."
> > > >
> > > > Let's do more testing and analyze if there any critical/blocker issues
> > > > for consideration.
> > > > Please raise here issues that you think MUST be fixed for M3.
> > >
> > > Agreed, thanks for the reminder. The focus moves onto testing what we
> > > have got, and raising any regressions or bugs that seriously inhibit
> > > areas of functionality. The goal is a stable build at the end of the mon
> th
> > .
> > >
> > > A MUST fix is removing the IDEA algorithm from the version of
> > > BouncyCastle that we redistribute -- see HARMONY-4810.
> >
> > I think the changes are not that simple
> >
> > We need to modify classes that refer to IDEA, for example
> > org/bouncycastle/jce/provider/BouncyCastleProvider.class
> >
> > it defines list of properties which specify implemented algorithms:
> >
> > public class a {
> > public static void main(String[] args) throws Exception {
> > java.security.Security.getProvider("BC").list(System.out);
> > }
> > }
> >
> >
> > $ java a | grep -i idea
> >
> > Alg.Alias.Mac.IDEA=IDEAMAC
> > Cipher.PBEWITHSHAANDIDEA-CBC=org.bouncycastle.jce.provider.JCEBloc...
> > Alg.Alias.AlgorithmParameters.PBEWITHSHAANDIDEA=PKCS12PBE
> > Cipher.IDEA=org.bouncycastle.jce.provider.JCEBloc...
> > KeyGenerator.IDEA=org.bouncycastle.jce.provider.JCEKeyG...
> > Alg.Alias.Mac.IDEA/CFB8=IDEAMAC/CFB8
> > AlgorithmParameters.IDEA=org.bouncycastle.jce.provider.JDKAlgo...
> > Alg.Alias.AlgorithmParameters.PBEWITHSHAANDIDEA-CBC=PKCS12PBE
> > Mac.IDEAMAC/CFB8=org.bouncycastle.jce.provider.JCEMac$...
> > Mac.IDEAMAC=org.bouncycastle.jce.provider.JCEMac$...
> > SecretKeyFactory.PBEWITHSHAANDIDEA-CBC=org.bouncycastle.jce.provider.JCESec
> r.
> > ..
> > AlgorithmParameterGenerator.IDEA=org.bouncycastle.jce.provider.JDKAlgo...
> >
> > And there are more classes with IDEA in their name:
> >
> > $ find . | grep -i IDEA
> > ./org/bouncycastle/asn1/misc/IDEACBCPar.class
> > ./org/bouncycastle/crypto/engines/IDEAEngine.class
> > ./org/bouncycastle/jce/provider/JCEBlockCipher$IDEA.class
> > ./org/bouncycastle/jce/provider/JCEBlockCipher$IDEACBC.class
> > ./org/bouncycastle/jce/provider/JCEBlockCipher$PBEWithSHAAndIDEA.class
> > ./org/bouncycastle/jce/provider/JCEKeyGenerator$IDEA.class
> > ./org/bouncycastle/jce/provider/JCEMac$IDEA.class
> > ./org/bouncycastle/jce/provider/JCEMac$IDEACFB8.class
> > ./org/bouncycastle/jce/provider/JCESecretKeyFactory$PBEWithSHAAndIDEA.class
> > ./org/bouncycastle/jce/provider/JCEStreamCipher$IDEA_CFB8.class
> > ./org/bouncycastle/jce/provider/JCEStreamCipher$IDEA_OFB8.class
> > ./org/bouncycastle/jce/provider/JDKAlgorithmParameterGenerator$IDEA.class
> > ./org/bouncycastle/jce/provider/JDKAlgorithmParameters$IDEAAlgorithmParamet
> er
> > s.class
> >
> > Thanks,
> > Mikhail
> >
> > >
> > > Shall we track these with an umbrella JIRA issue?
> > >
> > > As part of the code freeze, I'm going to resync the Java 6 branch.
> > >
> > > Regards,
> > > Tim
> > >
> >
>
Re: [general] M3 - code frozen
Posted by Mark Hindess <ma...@googlemail.com>.
Maybe we should just replace the IDEAEngine.class with a dummy class
that generates not implemented exceptions and reports how to get the
real version.
-Mark.
On 24 September 2007 at 17:31, "Mikhail Loenko" <ml...@gmail.com> wrote:
> 2007/9/23, Tim Ellison <t....@gmail.com>:
> > Stepan Mishura wrote:
> > > According to the plan - Sept. 22 is code freeze date for M3 so let's
> > > follow policy:
> > > "no more commits please without agreement from two committers on the dev
> list."
> > >
> > > Let's do more testing and analyze if there any critical/blocker issues
> > > for consideration.
> > > Please raise here issues that you think MUST be fixed for M3.
> >
> > Agreed, thanks for the reminder. The focus moves onto testing what we
> > have got, and raising any regressions or bugs that seriously inhibit
> > areas of functionality. The goal is a stable build at the end of the month
> .
> >
> > A MUST fix is removing the IDEA algorithm from the version of
> > BouncyCastle that we redistribute -- see HARMONY-4810.
>
> I think the changes are not that simple
>
> We need to modify classes that refer to IDEA, for example
> org/bouncycastle/jce/provider/BouncyCastleProvider.class
>
> it defines list of properties which specify implemented algorithms:
>
> public class a {
> public static void main(String[] args) throws Exception {
> java.security.Security.getProvider("BC").list(System.out);
> }
> }
>
>
> $ java a | grep -i idea
>
> Alg.Alias.Mac.IDEA=IDEAMAC
> Cipher.PBEWITHSHAANDIDEA-CBC=org.bouncycastle.jce.provider.JCEBloc...
> Alg.Alias.AlgorithmParameters.PBEWITHSHAANDIDEA=PKCS12PBE
> Cipher.IDEA=org.bouncycastle.jce.provider.JCEBloc...
> KeyGenerator.IDEA=org.bouncycastle.jce.provider.JCEKeyG...
> Alg.Alias.Mac.IDEA/CFB8=IDEAMAC/CFB8
> AlgorithmParameters.IDEA=org.bouncycastle.jce.provider.JDKAlgo...
> Alg.Alias.AlgorithmParameters.PBEWITHSHAANDIDEA-CBC=PKCS12PBE
> Mac.IDEAMAC/CFB8=org.bouncycastle.jce.provider.JCEMac$...
> Mac.IDEAMAC=org.bouncycastle.jce.provider.JCEMac$...
> SecretKeyFactory.PBEWITHSHAANDIDEA-CBC=org.bouncycastle.jce.provider.JCESecr.
> ..
> AlgorithmParameterGenerator.IDEA=org.bouncycastle.jce.provider.JDKAlgo...
>
> And there are more classes with IDEA in their name:
>
> $ find . | grep -i IDEA
> ./org/bouncycastle/asn1/misc/IDEACBCPar.class
> ./org/bouncycastle/crypto/engines/IDEAEngine.class
> ./org/bouncycastle/jce/provider/JCEBlockCipher$IDEA.class
> ./org/bouncycastle/jce/provider/JCEBlockCipher$IDEACBC.class
> ./org/bouncycastle/jce/provider/JCEBlockCipher$PBEWithSHAAndIDEA.class
> ./org/bouncycastle/jce/provider/JCEKeyGenerator$IDEA.class
> ./org/bouncycastle/jce/provider/JCEMac$IDEA.class
> ./org/bouncycastle/jce/provider/JCEMac$IDEACFB8.class
> ./org/bouncycastle/jce/provider/JCESecretKeyFactory$PBEWithSHAAndIDEA.class
> ./org/bouncycastle/jce/provider/JCEStreamCipher$IDEA_CFB8.class
> ./org/bouncycastle/jce/provider/JCEStreamCipher$IDEA_OFB8.class
> ./org/bouncycastle/jce/provider/JDKAlgorithmParameterGenerator$IDEA.class
> ./org/bouncycastle/jce/provider/JDKAlgorithmParameters$IDEAAlgorithmParameter
> s.class
>
> Thanks,
> Mikhail
>
> >
> > Shall we track these with an umbrella JIRA issue?
> >
> > As part of the code freeze, I'm going to resync the Java 6 branch.
> >
> > Regards,
> > Tim
> >
>
Re: [general] M3 - code frozen
Posted by Mikhail Loenko <ml...@gmail.com>.
2007/9/23, Tim Ellison <t....@gmail.com>:
> Stepan Mishura wrote:
> > According to the plan - Sept. 22 is code freeze date for M3 so let's
> > follow policy:
> > "no more commits please without agreement from two committers on the dev list."
> >
> > Let's do more testing and analyze if there any critical/blocker issues
> > for consideration.
> > Please raise here issues that you think MUST be fixed for M3.
>
> Agreed, thanks for the reminder. The focus moves onto testing what we
> have got, and raising any regressions or bugs that seriously inhibit
> areas of functionality. The goal is a stable build at the end of the month.
>
> A MUST fix is removing the IDEA algorithm from the version of
> BouncyCastle that we redistribute -- see HARMONY-4810.
I think the changes are not that simple
We need to modify classes that refer to IDEA, for example
org/bouncycastle/jce/provider/BouncyCastleProvider.class
it defines list of properties which specify implemented algorithms:
public class a {
public static void main(String[] args) throws Exception {
java.security.Security.getProvider("BC").list(System.out);
}
}
$ java a | grep -i idea
Alg.Alias.Mac.IDEA=IDEAMAC
Cipher.PBEWITHSHAANDIDEA-CBC=org.bouncycastle.jce.provider.JCEBloc...
Alg.Alias.AlgorithmParameters.PBEWITHSHAANDIDEA=PKCS12PBE
Cipher.IDEA=org.bouncycastle.jce.provider.JCEBloc...
KeyGenerator.IDEA=org.bouncycastle.jce.provider.JCEKeyG...
Alg.Alias.Mac.IDEA/CFB8=IDEAMAC/CFB8
AlgorithmParameters.IDEA=org.bouncycastle.jce.provider.JDKAlgo...
Alg.Alias.AlgorithmParameters.PBEWITHSHAANDIDEA-CBC=PKCS12PBE
Mac.IDEAMAC/CFB8=org.bouncycastle.jce.provider.JCEMac$...
Mac.IDEAMAC=org.bouncycastle.jce.provider.JCEMac$...
SecretKeyFactory.PBEWITHSHAANDIDEA-CBC=org.bouncycastle.jce.provider.JCESecr...
AlgorithmParameterGenerator.IDEA=org.bouncycastle.jce.provider.JDKAlgo...
And there are more classes with IDEA in their name:
$ find . | grep -i IDEA
./org/bouncycastle/asn1/misc/IDEACBCPar.class
./org/bouncycastle/crypto/engines/IDEAEngine.class
./org/bouncycastle/jce/provider/JCEBlockCipher$IDEA.class
./org/bouncycastle/jce/provider/JCEBlockCipher$IDEACBC.class
./org/bouncycastle/jce/provider/JCEBlockCipher$PBEWithSHAAndIDEA.class
./org/bouncycastle/jce/provider/JCEKeyGenerator$IDEA.class
./org/bouncycastle/jce/provider/JCEMac$IDEA.class
./org/bouncycastle/jce/provider/JCEMac$IDEACFB8.class
./org/bouncycastle/jce/provider/JCESecretKeyFactory$PBEWithSHAAndIDEA.class
./org/bouncycastle/jce/provider/JCEStreamCipher$IDEA_CFB8.class
./org/bouncycastle/jce/provider/JCEStreamCipher$IDEA_OFB8.class
./org/bouncycastle/jce/provider/JDKAlgorithmParameterGenerator$IDEA.class
./org/bouncycastle/jce/provider/JDKAlgorithmParameters$IDEAAlgorithmParameters.class
Thanks,
Mikhail
>
> Shall we track these with an umbrella JIRA issue?
>
> As part of the code freeze, I'm going to resync the Java 6 branch.
>
> Regards,
> Tim
>
Re: [general] M3 - code frozen
Posted by Tim Ellison <t....@gmail.com>.
Stepan Mishura wrote:
> According to the plan - Sept. 22 is code freeze date for M3 so let's
> follow policy:
> "no more commits please without agreement from two committers on the dev list."
>
> Let's do more testing and analyze if there any critical/blocker issues
> for consideration.
> Please raise here issues that you think MUST be fixed for M3.
Agreed, thanks for the reminder. The focus moves onto testing what we
have got, and raising any regressions or bugs that seriously inhibit
areas of functionality. The goal is a stable build at the end of the month.
A MUST fix is removing the IDEA algorithm from the version of
BouncyCastle that we redistribute -- see HARMONY-4810.
Shall we track these with an umbrella JIRA issue?
As part of the code freeze, I'm going to resync the Java 6 branch.
Regards,
Tim
Re: [general] M3 - code frozen
Posted by Tim Ellison <t....@gmail.com>.
Stepan Mishura wrote:
> On 9/22/07, Stepan Mishura wrote:
>> Hi,
>>
>> According to the plan - Sept. 22 is code freeze date for M3 so let's
>> follow policy:
>> "no more commits please without agreement from two committers on the dev list."
>>
>> Let's do more testing and analyze if there any critical/blocker issues
>> for consideration.
>> Please raise here issues that you think MUST be fixed for M3.
>
> Sorry, for late notification - I built and uploaded new M3 release
> candidate (r579330).
> Testing results will be available soon at:
> http://people.apache.org/~mloenko/snapshot_testing/script/r579330/index.html
Thanks Stepan. Please let us know (on a new thread) when it is done.
Regards,
Tim
Re: [general] M3 - code frozen
Posted by Stepan Mishura <st...@gmail.com>.
On 9/22/07, Stepan Mishura wrote:
> Hi,
>
> According to the plan - Sept. 22 is code freeze date for M3 so let's
> follow policy:
> "no more commits please without agreement from two committers on the dev list."
>
> Let's do more testing and analyze if there any critical/blocker issues
> for consideration.
> Please raise here issues that you think MUST be fixed for M3.
Sorry, for late notification - I built and uploaded new M3 release
candidate (r579330).
Testing results will be available soon at:
http://people.apache.org/~mloenko/snapshot_testing/script/r579330/index.html
Thanks,
Stepan.