Robert Pająk

> changing the spec so that SDKs can require chaining processors for making mutations. I will be unavailable for about next 3 weeks. I try to make some PR once...

I suggest to postpone until https://github.com/open-telemetry/opentelemetry-specification/pull/4067 is resolved.

@jsuereth @jmacd Any insights as I think you were involved in this area?

Personally I propose > 1. meter provider is created as meter's can be created before meter provider is created. I think it could be also more meaningful if there would...

**SIG meeting:** It is still unclear what is the expected value. This is also discussed in https://github.com/open-telemetry/opentelemetry-specification/pull/3540 CC @jmacd @jack-berg

I will have limited availability for next 3 weeks (almost none for next 2 weeks). I am totally fine (and even happy) if someone else (maybe @jmacd) would own the...

@open-telemetry/go-approvers @open-telemetry/cpp-approvers @open-telemetry/rust-approvers PTAL

@XSAM A shared log record means that consecutive processors receive the same instance of the log record. Not shared means that each log record record receives a copy of log...

> Now that https://github.com/open-telemetry/opentelemetry-specification/pull/4062 is merged, implementations like go and c++ that wish to keep log records on the stack can use the isolating processor to accomplish that, and document...

> It seems like an SDK would provide a new isolating log processor interface, with OnEmit accepting an alternative log record definition which is stack allocated and which has copy-on-write...