Marc Alff
> Thank you for running the workflow. The current GitHub workflow is only building the x64 artifacts. Should I duplicate the jobs so that there is a build for each...
Thanks for the report, labeling as a feature request. Guidelines for submitting a PR to implement this feature below. --- To support `X-Cloud-Trace-Context` propagation headers, it is necessary to implement...
For C++, current development is located here: * https://github.com/open-telemetry/opentelemetry-cpp/pull/2518
Now that there is some feedback on this for tracking, could the table itself be updated (because "we" do not have access right to do so) ? Thanks.
Note that this is a blind push. I could not get instructions to work to run tests: ``` [malff@malff-desktop opentelemetry-configuration]$ npm --version 6.14.11 [malff@malff-desktop opentelemetry-configuration]$ make npm install npm WARN...
Filed separately from comments on #76, so this can be discussed without affecting the merge of that PR.
> Couple of thoughts: > > * This would appear to add to the list of env vars which are unmapped defined in [Add sdk-config.yaml starter template w/ references to...
Using `otlphttp` and `otlpgrpc` sounds a viable option, and makes more sense with also `otlpfile`.
In my understanding, having implemented this for opentelemetry-cpp: For a native sampler (always_on), the schema is fixed, and the list of samplers known comes from the schema. For a custom...
So the question becomes, how to share a namespace between native and custom components.