David Ashpole

Do we want a migration plan? Or do we want to just want to switch to the new conventions?

I just need to implement the histogram metric now.

Some notes from my rough attempt to implement the histogram metric: * It has a lot of buckets (160?). See the source: https://github.com/golang/go/blob/355711821eea51c6456a31ab61d0dc2e9db034f7/src/runtime/histogram.go#L71 * It seems like the buckets may...

> ["buckets are power-of-2 sized"](https://github.com/golang/go/blob/355711821eea51c6456a31ab61d0dc2e9db034f7/src/runtime/histogram.go#L16) seems to motivate this 👍 It is powers-of-2 sized, but with linear "sub-buckets" between the power-of-two buckets. I asked, and the buckets are also subject...

I'm going to track adding the histogram metrics separately: https://github.com/open-telemetry/opentelemetry-go-contrib/issues/5974.

> But in the interim, having a detector here is probably the correct approach. @MrAlias Should we use feature environment variables instead of a new detector module?

Is that roughly the equivalent of using OTEL_HTTP_CLIENT_COMPATIBILITY_MODE, with Current: * Default = old * Supported = old, dup * Diff from current plan: no new Current + 1: *...

Added the PR to the 1.29 milestone, and removed this issue

Sorry I didn't see this the first time around. Taking a look now

I am able to reproduce the issue with these benchmarks: ```golang package bench import ( "testing" "go.opentelemetry.io/otel" ) const ( meterName = "foo" metricName = "bar" ) func BenchmarkSimple(b *testing.B)...