Mark initial set of HTTP semantic conventions as frozen #105
Conversation
|
Hopefully this is the last PR for https://github.com/orgs/open-telemetry/projects/41/views/4.
|
|
I kindly suggest taking a look at #128 before going Stable. When I read feature-freeze definition I feel that it may be too late. Hopefully, I am wrong. Personally, I do not feel comfortable that so many attributes are marked as |
Changes that address production issues with existing features are still accepted. |
I just want to share that the example of "mobile instrumentation" and PII is a real problem for one of our customers 😉 I do not have capacity to propose any PR in the following days (maybe even weeks). But I proposed some ideas in #128 |
I don't think this is meant for new production issues and critical things. Otherwise a missing feature could also cause production issues. |
|
If we want to address PII things, we need to lift the feature freeze (I think this will happen after stabilization is complete & released?) |
| @@ -55,6 +55,8 @@ operations. By adding HTTP attributes to metric events it allows for finely tune | |||
|
|
|||
| ### Metric: `http.server.duration` | |||
|
|
|||
| **Status**: [Experimental, Feature-freeze][DocumentStatus] | |||
There was a problem hiding this comment.
@trask what does it mean for a metric to have both experimental and Feature freeze simultaneously?
There was a problem hiding this comment.
Feature-freeze is orthogonal to Experimental/Stable https://github.com/open-telemetry/opentelemetry-specification/blob/ad1537a46eb856eeb915786fd7cf81e07bdeb426/specification/document-status.md?plain=1#L19.
(personally I find it counter intuitive - since only "Experimental", "Experimental + Feature-freeze" and "Stable" would make sense)
Fixes open-telemetry/opentelemetry-specification#3279