2006/12/1, Geir Magnusson Jr. <[EMAIL PROTECTED]>:
Mikhail Loenko wrote: > seems like we need to refersh our agreements aiming better stability. > There are questions to discuss and decision to be made. > > > 1) We have exclude list for each paltform and for two VMs. We have > discussed a separation of the common part but did not reach any > agreement. To make fixing VM- and platform-specific bugs easier I > suggest that we agree to separate a > common part. I thought we agreed. Either way, this is a side issue wrt regression. > > > 2) Usually committers check the classlib patches on J9 and then > commit. At this point checking the patches on DRLVM is not that > convinient so at the moment we don't ask committers to do classlib > pre-commit testing on DRLVM. Yes, and we're getting near the time to switch that. People have the freedom to do what they want, but we need to get this happening regularly. I'll do something to make it easier for this to happen - I'll make a "drop-n-go" snapshot of DRLVM so it can be dropped directly into classlib's deploy/jdk/jre/bin as /default. The only remaining issue that I can see is the infernal hythread.so problem. Would we solve that simply by renaming our hythread.so in DRLVM?
I've created corresponding JIRA yesterday: http://issues.apache.org/jira/browse/HARMONY-2362 And Salikh commented: "And the original dependent of hyprt.dll is laucher (java.exe): $ dumpbin /dependents java.exe ... Image has the following dependencies: HYPRT.dll ... Thus, it is not IBM VME to blame, but the launcher and/or hyprt.dll to be fixed to either - not depend on hythr.dll - to pick it up from VME directory" http://issues.apache.org/jira/browse/HARMONY-2364#action_12454671 So this issue is in progress now and I hope that it will be fixed soon. SY, Alexey
