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. 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. 3) CC should report each time state changes (pass to fail or fail to pass) and each time failure reason changed. Failure reason may change because some committers could miss failure notifiaction and do commit. Until we are able to say that failure reason has changed we report each failure and only the first success. 4) We have cruise controls running classlibrary tests on DRLVM. We need to decide what will we do when DRLVM+Classlib cruise control reports failure. IMHO It's pretty obvious that before we have found a commit causing that we stop further commits. 5) If the cause of failure is DRLVM commit than it's pretty obvious that we roll it back. 6) If the cause is Classlib test commit than we check wether the test is valid (e.g. run it on RI) and not VM-specific. If the test is valid we exclude it in DRLVM exclude list. If the test is invalid or VM-specific we roll it back or fix ASAP. 7) If the cause is a Classlib commit then this commit either reveals existing problem in DRLVM or introduces a regression. I don't have strong preferences here whether we'd better exclude the test or roll the commit back 8) We may also advise that committers don't commit changes just before going sleep or vacation. They should wait reasonable time to receive CC failure report if any. The problem is "reasonable time" is hardly predictable Comments? Thanks, Mikhail
