Update status of stdout exporter for logs to stable

[cijothomas]

https://github.com/open-telemetry/opentelemetry-specification/pull/3741/files and https://github.com/open-telemetry/opentelemetry-specification/pull/3740/files were added together, and it is not clear why one is experimental, and the other is stable.

This PR is marking the logging stdout exporter spec as stable. I couldn't find any reason why it was non-stable in the first place, so I assume it was just an oversight only. Happy to be corrected, if I missed something

Originally part of #3901

[MrAlias]

Do you think we need to clarify the output format of this exporter unspecified before we stabilize it?

[cijothomas]

Do you think we need to clarify the output format of this exporter unspecified before we stabilize it?

I don't see the need, as this is already stable for other signals, and none of them has a output format specified.

However, I do support the idea of spec-ing out the output format, and apply it for all signals. We should be able to do it in back-compat way (like opt-in to the new format) so don't have to block this.
(or since output format is not specified, it maybe okay to specify one without breaking spec's back-compat, and leave it upto individual implementations to decide if they want to opt-in to new format, etc.)

[MrAlias]

However, I do support the idea of spec-ing out the output format, and apply it for all signals. We should be able to do it in back-compat way (like opt-in to the new format) so don't have to block this.
(or since output format is not specified, it maybe okay to specify one without breaking spec's back-compat, and leave it upto individual implementations to decide if they want to opt-in to new format, etc.)

Hmm, this seems to be highlighting my underlying concern. We need to be transparent up-front that the output format is unspecified and that we won't ever try to standardize this format.

If we standardize our output format we will be specifying a data structure additional to the OTLP. We should instead require that user depend on that protocol if they want a stable and standardized data format.

I think we should go as far to say that language implementations are required to document their exporters as not providing a interoperable output and that that output itself is not guaranteed to be stable.

[cijothomas]

However, I do support the idea of spec-ing out the output format, and apply it for all signals. We should be able to do it in back-compat way (like opt-in to the new format) so don't have to block this.
(or since output format is not specified, it maybe okay to specify one without breaking spec's back-compat, and leave it upto individual implementations to decide if they want to opt-in to new format, etc.)

Hmm, this seems to be highlighting my underlying concern. We need to be transparent up-front that the output format is unspecified and that we won't ever try to standardize this format.

If we standardize our output format we will be specifying a data structure additional to the OTLP. We should instead require that user depend on that protocol if they want a stable and standardized data format.

I think we should go as far to say that language implementations are required to document their exporters as not providing a interoperable output and that that output itself is not guaranteed to be stable.

Does any of these need to block this PR, given span,metrics stdout exporter spec is already stable ?

[MrAlias]

Does any of these need to block this PR, given span,metrics stdout exporter spec is already stable ?

If omitting this kind of information was intentional in the trace and metric exporters, than I think we could proceed. However, I'm guessing not having this for those two signals was unintentional and just an oversight. We should try to address this prior to stabilizing so we don't make the same mistake a third time.

[cijothomas]

Does any of these need to block this PR, given span,metrics stdout exporter spec is already stable ?

If omitting this kind of information was intentional in the trace and metric exporters, than I think we could proceed. However, I'm guessing not having this for those two signals was unintentional and just an oversight. We should try to address this prior to stabilizing so we don't make the same mistake a third time.

I don't think it was an oversight, as #3565 existed well before https://github.com/open-telemetry/opentelemetry-specification/pull/3740/files was merged (as stable).

[MrAlias]

I don't think it was an oversight, as #3565 existed well before https://github.com/open-telemetry/opentelemetry-specification/pull/3740/files was merged (as stable).

Gotcha 👍, SGTM