Josh Suereth

Resource CANNOT change over the lifetime. A few reasons: - The [SDK specified resources are immutable](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/resource/sdk.md#resource-operations) which we rely on for many features. - [Metrics identity is tied to resource](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/metrics/data-model.md#opentelemetry-protocol-data-model)....

yes - Working on that, going to discuss with TC to make sure we have alignment, but for now let's stick to the guidance from this thread.

`host.ip` is an interesting conundrum. I'd say in many cases, it's stable enough to be acceptable in resource. In instances where it's unstable, and unstable frequently, we should not be...

Does this belong on the "core" Event abstraction, or as a semantic conventions? cc @jack-berg @MSNev

So a few points: 1. Exemplars are not guaranteed to cover important o11y scenarios. These are sampled and limited values. They are used to debug a *specific instance* of a...

To me Experimental + Feature-Freeze => Release candidate, but curious what other @open-telemetry/technical-committee folks think. IIRC - we did use Feature-Freeze on Stable components as well to denote no expected...

Just a note that sequentially != in the same thread. i'm going to try to reproduce now, with a slightly altered test-case.

Alright, so it appears the issue is more around "startup" and "shutdown". Currently in sbt, you are not guaranteed that "startup/shutdown" for a project will finish before the next test...

Current test case: https://gist.github.com/jsuereth/cec11c14412e365e90bf

> My initial preference would be to not maintain a separate data model description and focus on the OTLP representation. I'm assuming we can always come back to it and...