You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
What is the Problem?
Today some vendor contributed components are hosted on core repositories, others on separate repositories or separate organizations altogether. This fragmentation is very confusing for the user and the developers. The current state where vendor components reside in vendor-hosted organizations and repositories makes getting started with OpenTelemetry more difficult than it should be.
As an engineer contributing to the project for the past few months, I’ve often waited for code reviews (~20 days) and releases with my PRs to be made available upstream. Fellow engineers have had similar experiences. I figured the vendor specific components were lower priority and that the core maintainers were very busy.
Proposed Solution
There has been ongoing discussion to keep the vendor specific components in the OpenTelemetry repositories preferably in the -contrib repos. I propose that all vendor specific components for the OpenTelemetry JavaScript SDK reside in the github.com/open-telemetry/opentelemetry-js-contrib repository. This will reduce developer friction of having to navigate through different repositories to find the components they need. It will also facilitate a better user experience for anyone wishing to use OpenTelemetry with vendor specific components.
I request that vendor engineers have the ability to review and maintain their vendor specific components in the openetelemetry-js-contrib repository. We (as AWS) are very interested in maintaining these components for the project in the long-term. I think having shared responsibilities of reviewing and maintaining these components would also help reduce the burden of core maintainers who have to review vendor specific components. The core developers would be able to focus on core feature completion and code stability. This would help address the issue of fragmenting the getting started experience and increasing adoption.
For reference: there has been accepted specs to keep vendor code in the contrib repository of the collector and other contrib repositories as well.
As an engineer contributing to the project for the past few months, I’ve often waited for code reviews (~20 days) and releases with my PRs to be made available upstream. Fellow engineers have had similar experiences. I figured the vendor specific components were lower priority and that the core maintainers were very busy.
Just to add on this, even PRs related to non-vendor component were (imo) long to be merged, some waiting for more than a month (here, here or even the core repo here or here).
I definitely think we need to discuss adding approvers to get more reviews on PRs and potentially maintainers (since they are the only ones to merge PR) to merge them.
What is the Problem?
Today some vendor contributed components are hosted on core repositories, others on separate repositories or separate organizations altogether. This fragmentation is very confusing for the user and the developers. The current state where vendor components reside in vendor-hosted organizations and repositories makes getting started with OpenTelemetry more difficult than it should be.
As an engineer contributing to the project for the past few months, I’ve often waited for code reviews (~20 days) and releases with my PRs to be made available upstream. Fellow engineers have had similar experiences. I figured the vendor specific components were lower priority and that the core maintainers were very busy.
Proposed Solution
There has been ongoing discussion to keep the vendor specific components in the OpenTelemetry repositories preferably in the -contrib repos. I propose that all vendor specific components for the OpenTelemetry JavaScript SDK reside in the github.com/open-telemetry/opentelemetry-js-contrib repository. This will reduce developer friction of having to navigate through different repositories to find the components they need. It will also facilitate a better user experience for anyone wishing to use OpenTelemetry with vendor specific components.
I request that vendor engineers have the ability to review and maintain their vendor specific components in the openetelemetry-js-contrib repository. We (as AWS) are very interested in maintaining these components for the project in the long-term. I think having shared responsibilities of reviewing and maintaining these components would also help reduce the burden of core maintainers who have to review vendor specific components. The core developers would be able to focus on core feature completion and code stability. This would help address the issue of fragmenting the getting started experience and increasing adoption.
For reference: there has been accepted specs to keep vendor code in the contrib repository of the collector and other contrib repositories as well.
@alolita , @wilguo, @NathanielRN, @lupengamzn
The text was updated successfully, but these errors were encountered: