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 On Fri, Jul 28, 2017 at 4:45 AM, Gunnar Wagenknecht <[email protected]> wrote: > > If you consume (and redistribute) any Eclipse project, you inherit their > dependencies. Thus, there is no need to file CQs again.However, in theory > you need a CQ for the Eclipse OMR dependencies. > > Re-reading my own text breaks my head. :) > > Clarification: no need to file CQs for all of OMR's dependencies. In > theory you need just one CQ to the Eclipse OMR project itself. However, the > latter hasn't really been enforced across the board. > > -Gunnar > > > _______________________________________________ > incubation mailing list > [email protected] > To change your delivery options, retrieve your password, or unsubscribe > from this list, visit > https://dev.eclipse.org/mailman/listinfo/incubation > -- Wayne Beaton Director of Open Source Projects The Eclipse Foundation
_______________________________________________ incubation mailing list [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/incubation
