Highlight first party ownership in the ecosystem registry #4795
Comments
|
We have functionality it's just not enabled for all those upstream instrumentations, we can distinguish in the registry between "first party integrations" and "native": first party example: https://opentelemetry.io/ecosystem/registry/?s=kafkaflow We also have the integrations page to feature those: https://opentelemetry.io/ecosystem/integrations/ A piece missing is that this list of integrations shares the data from the registry, right now those are 2 independent data sets. We also leverage that second list to promote native (and only native) integrations on their language pages around libraries, e.g. https://opentelemetry.io/docs/languages/js/libraries/#use-natively-instrumented-libraries All of this also has a dependency with this terminology discussion (and everytime I tried to improve the situation I struggeld with finding the right words): open-telemetry/opentelemetry-specification#4089 So what can you do to help with that:
|
I'm working on this. As of this writing, there are 761 files that miss the flag: Changing 761 files in one PR will be too much. I'll breakdown the 761 files into separate batches using alphabetical order, one PR per batch. |
To address open-telemetry#4795, this is a series of PRs that add native or first party flags to registries that lack them. This batch touches collector-builder and all collector-exporter-* registries. Signed-off-by: Alex Ji <alji@cisco.com>
|
@haidong thanks so much for pitching in on this! |
|
Hey @haidong commented on your PR but adding the same here: what I was hoping for is a review of instrumentations (native and library) and apps and to verify if their instrumentation is first party means that it was created by the same org that provides the app or lib. Collector components are not part of that. Also components provided by the Otel community are not first party. Apologies once again and thank you for your eagerness to help. |
To address open-telemetry#4795, this is a series of PRs that add native or first party flags to registries that lack them. This batch touches and all collector-exporter-* registries. Signed-off-by: Alex Ji <alji@cisco.com>
To address open-telemetry#4795, this is a series of PRs that add native or first party flags to registries that lack them. This batch touches cpp and dotnet instrumentation registries. Entries whose repo url returns 404 are deleted.
To address open-telemetry#4795, this is a series of PRs that add native or first party flags to registries that lack them. This batch touches cpp and dotnet instrumentation registries.
To address open-telemetry#4795, this is a series of PRs that add native or first party flags to registries that lack them. This batch touches cpp and dotnet instrumentation registries.
To address open-telemetry#4795, this is a series of PRs that add native or first party flags to registries that lack them. This batch touches cpp and dotnet instrumentation registries.
To address open-telemetry#4795, this is part of a series of PRs that add isFirstParty or isNative flags to instrumentation registries that lack them. This batch touches Elixir, Erlang, and Go instrumentation registries.
To address open-telemetry#4795, this is part of a series of PRs that add isFirstParty or isNative flags to instrumentation registries that lack them. This batch touches Elixir, Erlang, and Go instrumentation registries.
To address open-telemetry#4795, this is part of a series of PRs that add isFirstParty or isNative flags to instrumentation registries that lack them. This batch touches Elixir, Erlang, and Go instrumentation registries.
To address open-telemetry#4795, this is part of a series of PRs that add isFirstParty or isNative flags to instrumentation registries that lack them. This batch touches Java instrumentation registries.
To address open-telemetry#4795, this is part of a series of PRs that add isFirstParty or isNative flags to instrumentation registries that lack them. This batch touches Java instrumentation registries.
To address open-telemetry#4795, this is part of a series of PRs that add isFirstParty or isNative flags to instrumentation registries that lack them. This batch touches JavaScript instrumentation registries.
To address open-telemetry#4795, this is part of a series of PRs that add isFirstParty or isNative flags to instrumentation registries that lack them. This batch touches JavaScript instrumentation registries.
To address open-telemetry#4795, this is part of a series of PRs that add isFirstParty or isNative flags to instrumentation registries that lack them. This batch touches PHP instrumentation registries.
To address open-telemetry#4795, this is part of a series of PRs that add isFirstParty or isNative flags to instrumentation registries that lack them. This batch touches Python instrumentation registries.
To address open-telemetry#4795, this is part of a series of PRs that add isFirstParty or isNative flags to instrumentation registries that lack them. This batch touches Ruby instrumentation registries.
To address open-telemetry#4795, this is part of a series of PRs that add isFirstParty or isNative flags to instrumentation registries that lack them. This batch touches Lua/Perl/Rust/Swift instrumentation registries.
Desired feature or idea:
Similar to how there is highlighting of code maintained by us, I'd like to see highlighting of first party ownership of instrumentation, exporters, etc in the ecosystem registry.
For example, this project is maintained by us
These two are maintained by the upstream project (first party), something you can tell by name comparison, but it isn't annotated otherwise
I'd love to see a stylesheet or otherwise change based on a flag in the registry data of "isUpstream" negate of "isThirdParty" or similar, so that end users can know something in the registry is authoritatively owned.
Additional context:
While it is easy to tell which instrumentation are done by us, it is not easy to tell which are done by the upstream owners. We make a call that is in my opinion correct, that the very first priority is that the instrumentation is upstream. By highlighting we encourage the same behaviors in our registry as our policy, and make it easier for end users to know if something is neither maintained by us, nor by the project owner. For example, they can prefer something that isn't a vendor-specific codebase which is neither subject to review of the target owners, nor ours.
The text was updated successfully, but these errors were encountered: