Robert Pająk
Robert Pająk
Possibly related: https://github.com/open-telemetry/opentelemetry-specification/issues/4494#issuecomment-2881606881
@ywwg, I think this is a good idea. I see that `otlptranslator` [depends on `pdata`](https://github.com/prometheus/otlptranslator/blob/5262e704d71757fc689a99c79e98963a4ee6b37e/go.mod#L10) from Collector. Is it possible that `otlptranslator` would remove this dependency so that we have...
>> Would it be a problem to wait until that actually happens, and then fix it? > That's what I'm arguing for. Let's not create a problem for ourselves unless...
> But its dependence on open telemetry means the code necessarily needs to be a collaboration between the two organizations because it is the critical interface point between the two...
> Could you explain how it would be harder to maintain a free-standing (i.e. independent of the Collector) OTel library containing the metric type definitions, rather than duplicating them between...
> [@pellared](https://github.com/pellared) What do you think of a spike that uses the prometheus/otlptranslator [branch containing the OTel metric type definitions](https://github.com/prometheus/otlptranslator/pull/29), in open-telemetry/opentelemetry-collector-contrib and open-telemetry/opentelemetry-go? I think it would be valuable...
This looks to be introduced in: - https://github.com/open-telemetry/opentelemetry-go-contrib/pull/7233 @bacherfl, are you able to take a look at this issue?
@bacherfl, are you still looking into it or should I make this issue unassigned?
@open-telemetry/go-maintainers, do you think that there anything more that I should add/check in order to validate the https://github.com/open-telemetry/opentelemetry-specification/pull/4485?