I'll fill this out shortly.
Key deliverables are - how we manage consumption of artifacts and specs by 3rd party open source projects that use ONAP.

The code freeze of acumos is slightly behind onap - proposal is to work the Dublin spec during RCx in onap - ready for ONAP consumption without further changes - as we work it out with Acumos during the end of casablanca
Note the acumos personnel from AT&T are the same one involved with Portal in ONAP

Key points are spec and implementation
spec is complete
but implementation in ONAP is not - as expected because we will iterate adoption of the spec - starting in onap portal/sdk. Until then acumos has started iterating the spec - hence our tight integration and the benefit to ONAP

An example is
onap needs support from the JAX-RS spec for jackson library upgrades (as part of Java EE 8/9)
and acumos needs support from the Casablanca/Dublin release of ONAP - where we need to define the timeline and size of work to implement a reference logging library by retrofitting the portal/sdk library with the proposed dublin spec.

Currently Acumos pulls artifacts and architecture (logging, some kubernetes, ELK stack...) from ONAP (they keep in sync)
We currently have no formal process for maintaining this relationship.
Currently the PTLs and developers involved that work on both sides manage this.

updated
https://wiki.onap.org/display/DW/External+Open+Source+Community+Coordination