Trask Stalnaker

> Applying filters to the java.util.logger in our application did not work as the same filters were not applied to the opentelemetry loggers hi @hsraps, can you explain why this...

> The question is if we want to live with the "defect" we currently have in the HTTP conventions, or find another solution like normalization (nontrivial) isn't this defect solved...

hi @cheempz! we have had some recent discussions about this in semantic conventions, and the direction we're going (you can see this in http and database semantic conventions already) is...

For Java repos (and a couple other examples in OTel I've seen), we have a scheduled workflow in the downstream repo that watches for releases in the upstream repo, e.g....

> Not all Events that are emitted in the course of a span's execution should be associated to the span, so how would we figure out when we do and...

> Representing Events as SpanEvents is this only needed for backwards compatibility, i.e. so we can move existing SpanEvents over to Events? if so, then we could drop the need...

> if an event is just a named log record, why do we need two notions? I'm getting more comfortable with the idea that an event is just a named...

my 2c from https://github.com/open-telemetry/opentelemetry-specification/pull/2755#discussion_r966486350: > I prefer `*enabled` flags over `*disabled` flags (even if that means the default value is true), and we use this pattern for all boolean flags...

just sharing a data point, I suspect we won't change `OTEL_INSTRUMENTATION_[NAME]_ENABLED` in the Java agent, since some of the instrumentations are enabled by default and some are disabled by default,...

> I am not sure if this would need a sponsor this is a relatively small (if not uncontroversial) change, so I don't believe a sponsor is needed