Tyler Helmuth

To touch on points 2 and 3 in the issue for a bit: Based on the discussed criteria so far, the Core distribution would no longer be supported. I believe...

> Sure, it's tolerable for most use-cases, but it's not serving a specific purpose. I see it's specific purpose to be a dev tool - something that helps users get...

@djaglowski that is a super good point. I like the idea of making that criteria less strict so that we don't limit our options. How about: - Distributions supported by...

@mx-psi can you describe more about why being less strict with the release assets is a good thing. Is it to make it easier to accept new distributions that might...

@mx-psi would you distill the current proposal down to: - Distributions supported by the Collector must include the following assets except where the specific purpose of the distribution is naturally...

> I think this is a problem with having more than one distribution, not with core specifically. We also see that with ADOT distros (e.g. see https://github.com/open-telemetry/opentelemetry-collector-contrib/issues/13163 or https://github.com/open-telemetry/opentelemetry-collector-contrib/issues/8109). I...

Continuing this Issue's discussion, here are my proposed criteria for what should be included in Contrib: 1. All components from opentelemetry-collector and opentelemetry-collector-contrib that have at least 1 signal at...

@jpkrohling [this comment here](https://github.com/open-telemetry/opentelemetry-collector-releases/issues/360#issuecomment-1608294114) is my take on why Contrib meets the criteria we've been discussing and why Core doesn't. For Core, I think it comes down to the criteria...

> I guess we need a new dimension then on the support table: are we talking about support for production use-cases, or for dev/PoC? Contrib is great for dev/PoC, but...

We haven't landed on the presentation of the outcome of this discussion yet but a table seems reasonable.