Damien Mathieu

> So context based solution would not reset it for the whole subtree, but merely for the immediate child. At the discretion of the instrumentation library author for that child...

This wouldn't be enough, as several SDKs (at least Go) initiatialize a noop span when a no-sample decision was made. Changing that decision would mean having to regenerate a full...

> Tail-sampler with SpanProcessor can only export spans in current process 4 no-sample trace bcause it does't change sample flag Yes. If you do tail-sampling in the span processor, you...

I would tend to agree with the reasoning that having "none" among other propagators doesn't make sense and looks like a config mistake.

My take from discussion, as someone who's tinkering both the profiling SIG and the collector is that the dictionary makes data manipulation in the collector rather harder. It's definitely a...

For the record, Go allows doing this with the [trace.ContextWithSpanContext](https://pkg.go.dev/go.opentelemetry.io/otel/trace#ContextWithSpanContext) and [trace.ContextWithRemoteSpanContext](https://pkg.go.dev/go.opentelemetry.io/otel/trace#ContextWithRemoteSpanContext) methods, which allows injecting a span context into the context.

Rather than have one sampling doc in each SDK (that'll be the same everywhere), should there be a global one that SDK docs can link to?

Yes, they should be fixed now.

There are already tags. See https://github.com/open-telemetry/opentelemetry-ebpf-profiler/releases/tag/v0.0.202527 As for a stable version, the OTLP portion needs to be made stable first. Then, we'll need to ensure proper backwards compatibility. So no...

Are you using a custom span exporter? `Shutdown()` on the tracer provider calls the same method on each span processor, which calls it on each span exporter. https://pkg.go.dev/go.opentelemetry.io/otel/sdk/trace#SpanExporter > //...