Proposal: Move Extra packages out of this repo into a opentelemetry-rust-contrib

[hdost]

Following reading more on the IdGenerator I was also taking a look at some of the other language repos, and I wonder if there shouldn't be a opentelemetry-rust-contrib repo created to hold anything outside the "core".

Updated on 2023-11-02 for consistency with the repo.

Keep in Primary:

• opentelemetry
• opentelemetry-http
• opentelemetry-jaeger
• opentelemetry-otlp
• opentelemetry-prometheus
• opentelemetry-proto
• opentelemetry-sdk
• opentelemetry-semantic-conventions
• opentelemetry-stdout
• opentelemetry-zipkin
• opentelemetry-appender-log - For log which is a crate maintained by Rust Lang team
• opentelemetry-appender-tracing - Keep for now, might be deleted or merged into tracing-opentelemetry later

Move to Contrib:

• opentelemetry-aws
• opentelemetry-contrib
• opentelemetry-datadog
• opentelemetry-dynatrace
• opentelemetry-stackdriver
• opentelemetry-user-events-logs
• opentelemetry-user-events-metrics
• opentelemetry-zpages

Additional IdGenerator implementing vendor-specific protocols such as AWS X-Ray trace id generator MUST NOT be maintained or distributed as part of the Core OpenTelemetry repositories.

Source: https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/trace/sdk.md#id-generators

Java: https://github.com/open-telemetry/opentelemetry-java-contrib/tree/main/aws-xray

[TommyCpp]

I think that makes sense. The discussion around this before was worried about it will be harder to maintain two separate repos.

We also publish a contrib crate that basically includes anything is not in standard but not complicate enough for a separate crate.

[djc]

It's not obvious to me why Jaeger, Prometheus and Zipkin are in core and the others aren't?

[TommyCpp]

It's not obvious to me why Jaeger, Prometheus and Zipkin are in core and the others aren't?

Those exporters are defined in spec as something SDK should support.

Another way to think about this is whether we want to maintain the model between this repo and contrib repo. Contrib repo is a great tool if some component is supported by a specific group of ppl. For example, AWS has been maintaining AWS x-ray in Java IIRC.

[hdost]

I think that makes sense. The discussion around this before was worried about it will be harder to maintain two separate repos.

We also publish a contrib crate that basically includes anything is not in standard but not complicate enough for a separate crate.

Something like this could make sense as well.
Would it also make sense to move it out into a separate workspace
Perhaps
<project root>/contrib

[djc]

I think we should keep all the crates maintained by this org in a single workspace, so that we can benefit from centralized maintenance when core APIs change. I guess we could stuff some crates in a contrib dir, but I don't really see the point.

[hdost]

The most salient thing I can think of would be related to the MSRV and tying the "contribs" to the main could conflate the two.

Granted I'm sure it would be good to keep a decent pace.

Clarification that I don't mean at the crate level since thats where its set but in terms of CI.

[hdost]

In the SIG we spoke about delaying this until at least trace and metrics are stable.

Cc: @cijothomas @TommyCpp

[cijothomas]

I understand we discussed this few months ago, but based on the discussions in the SIG meeting yesterday, want to make this happen sooner, to keep the repo only have the core-components needed to declare stable. There are too many components, and they make the CIs slow, and also take away focus from the core goal. Moving non-core to contrib repo should help keep more focus on core. (There is related topic of doing frequent, predictable release frequency as well.)