It pains me to disagree with Gunnar in a public forum :-)
CQs are not required in theory or in practice in order to consume the artifacts of another Eclipse project. We would require a CQ if you chose to fork the code of another Eclipse project, but I'd probably spend a lot of time trying to talk you out of creating a fork (thereby making it far more trouble than it's worth). I'm confident that you're not talking about forking anything.
OMR doesn't produces binary builds AFAIK. It is the nature of the project that all it produces is source. The Eclipse Development Process tends to assume that projects produce some sort of binary output based on our source code, so we're in a bit of a grey area. Normally, one project can only include officially released (via release review) bits from another Eclipse project.
OpenJ9 can just pull from OMR Git repositories as part of its own build. No CQs or explicit tracking will be required.
Given my assumption that OMR doesn't produce any sort of typical build, I believe that the correct course of action is to coordinate releases (and release reviews) for OMR and OpenJ9. For OMR, the release event may just be a tag in the repository.
Best effort should be taken to provide some sort of pointer back to the OMR project in the bits that are pulled from that project, so that, e.g. a consumer can have a reasonable chance of finding their way back to the source. This might simply take the form of a sentence that describes the relationship in the OpenJ9 project's contribution guide.
I hope that at least some of this makes sense.
Wayne
