Robert Pająk

The current proposal is to try using code generation to make sure that modules are not coupled because of "internal dependencies". From https://github.com/open-telemetry/opentelemetry-go/pull/3805#issuecomment-1446839229: > Code generation that produces duplicates and...

Blocked by https://github.com/open-telemetry/opentelemetry-go/issues/3846

Closing as I think the value is not worth the cost.

https://github.com/open-telemetry/opentelemetry-go/pull/4804 was applied to fix OpenTracing Bridge and add functions that are not entangled with W3C Propagator. I am not closing the issue as we can still consider deprecating all...

One problem is to make it "experimental" in SDK, the other is to make it available for API users. > Maybe under an isolated module that could clearly/cleanly document that...

How about ```go s, ok := span.(interface { AddLinks(links ...Link) }) if ok { s.AddLinks(links...) } ``` This feature would need to be documented in the SDK docs and clearly...

On the other side, I do not see a lot of demand for this feature. Therefore, I think it may be better to wait until it is stable in the...

I doubt that we will have a consensus to define an experimental feature using anonymous type assertions. _Personally, I am rather against this idea. However, I do my best to...

I created https://github.com/open-telemetry/opentelemetry-specification/issues/3865

**SIG meeting notes:** After a discussion, it looks like this it is a bug with how the noop providers handles context propagation. Using noop provider may be a clean solution...