Andrew Wilkins

>> By default (no encoding specified), we create an OTLP log record for each CloudWatch log event within the payload. The log event message will be used exactly as-is, and...

> Sorry, I don't follow... Maybe you thought I meant that `cloudwatch::encoding` would apply to the individual log events still? To clarify, I'm on board with having the encoding apply...

I tend to agree. IIANM the component name in a changelog entry is not strictly enforced, e.g. it can be something like "kafka" if it corresponds to all of the...

For posterity, I raised this on Slack (https://cloud-native.slack.com/archives/C07CCCMRXBK/p1749699194132449): @atoulme informed me chloggen already has a means of restricting the component list in the changelog, we would just need to set...

@julealgon fair enough! I also don't know it deeply, but I've taken a stab at an enhancement request here: https://github.com/open-telemetry/opentelemetry-go-build-tools/issues/971

@atoulme good point, maybe AddrConfig should be split into client & server configs too - I would keep that as a separate effort though. Transport is relevant, that's how we...

I agree that the collector should have something built in for this. A few thoughts: Defaulting to omitting details is IMO best, but there should probably be a way for...

> or shared in a multi-tenant setup This is a legitimate setup. In such a setup, clients of the collector should typically not be privy to details of the backend,...

> The reason we set this for receiver/otlp as we believe the errors were returned from the receiver (might be wrong here) from the data validation before even reaching to...

Issue created by code owner, removing needs-triage.