Jack Berg

> My preference would be to move "bridges to other telemetry libraries" to the contrib repository, where experts in the target libraries can be component owners for them. Doesn't the...

> Which sounds super vague, but I think somewhat makes sense Ideally the definition we land on is unambiguous so we don't have to keep revisiting the decision in the...

We spoke in the 8/25/2022 Java SIG about a variety of topics related to where components should live within the three otel java repositorys `opentelemetry-java`, `opentelemetry-java-instrumentation`, and `opentelemetry-java-contrib`. To summarize:...

@anuraaga I'm not sure I'm following - is there something in the spec that is ambiguous about _which_ resource attributes are included? This [section](https://github.com/open-telemetry/opentelemetry-specification/blame/main/specification/metrics/data-model.md#L1400) feels fairly straight forward. Additionally, this...

> Even if a user doesn't need target_info, Prometheus will still scrape and save it Yes that's true. But prometheus should already be ascribing unique instance ids to the metrics...

Talked about this in spec issue [2640](https://github.com/open-telemetry/opentelemetry-specification/issues/2640#issuecomment-1190496761) and I've come away thinking no change is needed to the specification and we should move forward with this PR. The TL;DR is...

> not sure, can it really join across series with label changes? I believe yes, but users will likely be joining on `instance`, so a lot will depend on how...

Transferring to `opentelemetry-java`.

You can create `Attributes` as follows: - `Attributes.builder().put("key1", "value1").put("key2", "value2").build()` - `Attributes.of(AttributeKey.stringKey("key1"), "value1", AttributeKey.stringKey("key2"), "value2")`

They are alternatives to each other. The second option is best for when you know all the attribute keys ahead of time.