Deprecate k8slogreceiver if no further development is planned

[ChrsMark]

Component(s)

receiver/k8slog

Describe the issue you're reporting

The k8slog receiver has been landed for a while now but it comes with no actual implementation yet. Only the initial PR was merged (with no solid consensus during the review) and there was no follow-up.

I wonder if this should be deprecated and removed if there is no intention to continue the work there.
The component has been in development since its introduction so removing it won't have any serious impact.

Tip

_{React with 👍 to help prioritize this issue. Please use comments to provide useful context, avoiding +1 or me too, to help us triage it. Learn more here.}

[github-actions]

Pinging code owners:

• receiver/k8slog: @h0cheung @TylerHelmuth

See Adding Labels via Comments if you do not have permissions to add labels yourself.

[logicfox]

There is activity in the parent issue linked in the PR.

[ChrsMark]

There is activity in the parent issue linked in the PR.

I'm not sure if this activity can be considered significant enough, it mostly seems to be questions and comments from people but nothing into the direction of progressing the component.

I also believe that the initial PR did not reach consensus regarding the component's design. Given that there have not been concrete actions to progress this I wonder if it should still be hosted in Contrib repository. It can always live in a 3rd party repository until it's ready to become part of contrib.

[logicfox]

Agree that the original PR did not reach consensus. But this component can address a fairly common case of using the collector as a sidecar. The suggested use of the Core V1 API might actually be a clean implementation and potentially the least hacky solution. I would like to take a stab at it.

[atoulme]

We don't build consensus in PRs. We build consensus in the sponsoring issue for the component. Once a component is accepted, we implement it. We took way too long to merge the first PR and that stalled further development.

@h0cheung are you still looking to build this component? If not, we can move you to emeritus status, and we will move the component to unmaintained. After 3 months unmaintained, the component will be removed.

[ChrsMark]

We don't build consensus in PRs. We build consensus in the sponsoring issue for the component. Once a component is accepted, we implement it. We took way too long to merge the first PR and that stalled further development.

Just to clarify, I meant consensus in the unresolved comments as #24439 (comment) mentioned.

[h0cheung]

I'm sorry, due to a shift in business direction, I am no longer responsible for observability-related work. Since @logicfox is willing to try to implement it, I think he can take over, and I am very grateful for his contribution.