Consider separating out git repository for tracing from metrics

[open-telemetry]

Consider separating out git repository for tracing from metrics

[jmacd]

I believe when we reach a point of maturity, it will be feasible to make this separation. Currently, it's the context propagation stuff that binds metrics and tracing. There are a bunch of issues asking for this to be separated from OTel proper (e.g., open-telemetry/opentelemetry-specification#70). When this is done, we can split the core library into three repos (context, metrics, tracing). We also have discussed eventually moving the exporters out, because they have random dependencies that most users don't want to build (e.g., Jaeger->Thrift).

[tedsuo]

Hi @cep21. There is definitely the issue of clean API design. However, as @jmacd mentioned, the observability APIs do end up sharing certain concepts, which we are in the process of separating more decisively. One example include correlations, where independent observations - including those made across different observability APIs - can be indexed and associated with each other. Another example includes context propagation, where all observability systems use the same subsystem for transmitting their data.

I can repo separation of core components happening as part of the process of transitioning to a long term support guarantee for the v1.0. But pulling some of what are currently SDK innards out into plugins can happen sooner.

You mentioned the observability APIs, but for me, it's actually moving the context propagation mechanism into its own repo which I would really like to see. Ensuring that context propagation is cleanly separated into a lower layer will help drive adoption of that mechanism, and will make it easier to share with gRPC and other projects, as we know that some groups would feel odd about depending on an observability project for their context propagation. :)

[jmacd]

I will propose we set a date sometime after our Alpha release and sometime before our Beta releases begin, to split the repository into packages along the lines that you suggest. We need to flush our more on context propagation, which binds these two together.

[jmacd]

See also #261

[rghetia]

closing this unless it is mandated by the specification.