How to handle explicit deviations to the spec?

[jpkrohling]

During the discussion of open-telemetry/oteps#232, a previous version of that proposal stated that language SIGs would only be considered stable once they implemented the stable parts of the API and SDK specs. The dotnet maintainers brought up the point that not everything in the spec makes sense for dotnet, and it shouldn't prevent the dotnet SDK/API from being called stable.

While the dotnet-specific parts are interesting, I think we have a more generic matter to discuss: if a SIG determines that a required part of the spec shouldn't be implemented, should the deliverable still be considered stable? Who should make this call? Should a TC waiver be provided?

[jpkrohling]

More context: open-telemetry/oteps#232 (review)

[trask]

My initial inclination would be to have these deviations documented somewhere in this repository, where they will get visibility and implicit sign-off from TC members via PR.

[MrAlias]

My understanding of this statement is pretty clear, the .NET implementation is not compliant if they do not satisfy all the requirements:

An implementation of the [specification][] is not compliant if it fails to
satisfy one or more of the "MUST", "MUST NOT", "REQUIRED", "SHALL", or "SHALL
NOT" requirements defined in the [specification][]. Conversely, an
implementation of the [specification][] is compliant if it satisfies all the
"MUST", "MUST NOT", "REQUIRED", "SHALL", and "SHALL NOT" requirements defined in
the [specification][].

If parts of the specification are not applicable or don't make sense for an implementation they need to work with the specification to modify it so they can comply with it. Otherwise, whats the point of having a specification?

[Oberon00]

I also think that the .NET model of implementing most core things in the Microsoft-owned dotnet/runtime repository does not align well with OpenTelemetry procedures and governance. Instead of declaring it "stable" it is more like "N/A" and despite the name opentelemetry-dotnet is not really an OpenTelemetry implementation but a project that provides functionality very similar to OpenTelemetry for .NET. Definitely similar enough to warrant not re-implementing an OpenTelemetry client library for .NET, but it's not really a full OpenTelemetry either.

[atoulme]

Bringing over my comment from the discussion on OTEP 232:

I think that given the large scope of the specification and SDKs, the specification should come with a set of functional tests covering portions of the specification, against which SDKs can test and declare themselves stable when they pass all tests.

[austinlparker]

The GC is going to handle creating a policy around this

[jpkrohling]

@austinlparker, do you remember if there was movement around this already?

[austinlparker]

@austinlparker, do you remember if there was movement around this already?

I don't think it's made it to an agenda yet.