Joshua MacDonald

I am happy with the latest developments in the batching support. We still require the queue sender to enable concurrency in the batch processor => so we have back-pressure but...

These changes are very disruptive for developers with in-flight work. I wonder if we could evaluate the cost/benefit? Or, could we have the deprecation schedule be longer, to give those...

@marcinsiennicki95 there is a connection between Arrow and Parquet, but it is not an automatic translation. The way we have structured the OTel-Arrow data stream, there are multiple logical tables...

(Teaser: I've been playing around with an Parquet-first telemetry data store, it's helped me come to concrete opinions about this problem. https://github.com/jmacd/duckpond)

https://github.com/open-telemetry/oteps/pull/247 (see also)

We are blocked on https://github.com/open-telemetry/opentelemetry-collector-contrib/pull/33579

This is in progress. We will not develop new PRs in this repo, and the components will be deleted (which requires some effort). See also https://github.com/open-telemetry/opentelemetry-collector-contrib/issues/33567.

If I check for MaxUint16 at the location where `metricID` is allocated, I get an error like this: ``` panic: github.com/open-telemetry/otel-arrow/pkg/otel/arrow_record.(*Producer).BatchArrowRecordsFromMetrics:224->github.com/open-telemetry/otel-arrow/pkg/otel/metrics/arrow.(*MetricsBuilder).Append:186->integer overflow ``` This is hardly an improvement -- @lquerel...

We will have to hold off on actually deleting the components here until the components are actually usable in a collector-contrib release. However, development has moved, see: [[otelarrowreceiver] Ensure consume...

I support both `system.uptime` and `process.uptime` semantic conventions.