Apologies if this already has been discussed.
Context
The Python SIG has almost all of their instrumentations supporting the old semantic conventions. Only one and a half (one in draft) of the instrumentations have implemented the http semantic conventions migration plan. Recently, we have had contributions/inquiries about our instrumentations that either require an upgrade to the new semantic conventions or is providing a fix/addition to upgrade SOME of an instrumentation to follow new http semantic conventions (e.g. open-telemetry/opentelemetry-python-contrib#2260). We do not want our instrumentations to be in a mixed state, and it is better from a maintenance standpoint to migrate instrumentations entirely and individually. This poses an issue as we are now either forced to block contributors from making contributions to instrumentations that relate to new semantic conventions or introduce a mixture of new semantic conventions with already existing old ones (we don't want to do this).
Issue
The main issue is that the Python SIG, which is already suffering from lack of resources, will not be able to implement the migration plan for all our instrumentations within a reasonable time (specifically allowing configuration for old/new/double pump), however there are users and contributors who are waiting on us to do so. It's possible that this work could take longer than a year, given our lack of contributors. This most likely is an issue in other language SIGs as well. We would like some guidance on how to EASE the burden and implementation work for contributors to be able to ship out new semantic conventions in a reasonable amount of time. For context, it took me (a Python maintainer and also following the http semantic conventions work relatively closely) a couple of days to implement the migration plan for a SINGLE instrumentation (open-telemetry/opentelemetry-python-contrib#2002) and even longer to review and approve from other approvers since most people do not have context about the migration or even semantic convention changes in general (I do admit that there was no migration guide at the time of implementing it and perhaps I am just slow :D).
Possible mitigations
-
Allow a deadline for implementation of the migration plan for instrumentations. If we are passed the deadline and the instrumentation still has not implemented the migration plan, we allow language SIGs to make the decision on whether they want to simply upgrade to new semantic conventions for the next released version of the instrumentation and break users. This is at least possible for Python since all of our instrumentations are experimental. This will at least alleviate SOME implementation burden, and allow contributors that do not have context on the migration plan to assist in simply implementing the new semantic conventions.
-
Allow leniency on WHICH instrumentations must implement the migration plan. We can allow language SIGs to decide which instrumentations they want to implement the migration plan (most likely for the most popular libraries) in a best effort, and allow breakage for every other instrumentation. The instrumentation chosen should be explicitly outlined in whatever migration guidance/documentation language SIGs have.
@trask for visibility
Apologies if this already has been discussed.
Context
The Python SIG has almost all of their instrumentations supporting the old semantic conventions. Only one and a half (one in draft) of the instrumentations have implemented the http semantic conventions migration plan. Recently, we have had contributions/inquiries about our instrumentations that either require an upgrade to the new semantic conventions or is providing a fix/addition to upgrade SOME of an instrumentation to follow new http semantic conventions (e.g. open-telemetry/opentelemetry-python-contrib#2260). We do not want our instrumentations to be in a mixed state, and it is better from a maintenance standpoint to migrate instrumentations entirely and individually. This poses an issue as we are now either forced to block contributors from making contributions to instrumentations that relate to new semantic conventions or introduce a mixture of new semantic conventions with already existing old ones (we don't want to do this).
Issue
The main issue is that the Python SIG, which is already suffering from lack of resources, will not be able to implement the migration plan for all our instrumentations within a reasonable time (specifically allowing configuration for old/new/double pump), however there are users and contributors who are waiting on us to do so. It's possible that this work could take longer than a year, given our lack of contributors. This most likely is an issue in other language SIGs as well. We would like some guidance on how to EASE the burden and implementation work for contributors to be able to ship out new semantic conventions in a reasonable amount of time. For context, it took me (a Python maintainer and also following the http semantic conventions work relatively closely) a couple of days to implement the migration plan for a SINGLE instrumentation (open-telemetry/opentelemetry-python-contrib#2002) and even longer to review and approve from other approvers since most people do not have context about the migration or even semantic convention changes in general (I do admit that there was no migration guide at the time of implementing it and perhaps I am just slow :D).
Possible mitigations
Allow a deadline for implementation of the migration plan for instrumentations. If we are passed the deadline and the instrumentation still has not implemented the migration plan, we allow language SIGs to make the decision on whether they want to simply upgrade to new semantic conventions for the next released version of the instrumentation and break users. This is at least possible for Python since all of our instrumentations are experimental. This will at least alleviate SOME implementation burden, and allow contributors that do not have context on the migration plan to assist in simply implementing the new semantic conventions.
Allow leniency on WHICH instrumentations must implement the migration plan. We can allow language SIGs to decide which instrumentations they want to implement the migration plan (most likely for the most popular libraries) in a best effort, and allow breakage for every other instrumentation. The instrumentation chosen should be explicitly outlined in whatever migration guidance/documentation language SIGs have.
@trask for visibility