Drop support for `ruby-kafka`

[arielvalentin]

This gem is deprecated and no longer receiving updates

https://github.com/zendesk/ruby-kafka?tab=readme-ov-file#deprecation-notice

0. Release a deprecation notice
1. Remove ruby-kafa from all
2. Remove ruby-kafka from releases
3. Introduce an archive process the keeps the existing source in the repo for reference only

[kaylareopelle]

Some inspiration for component lifecycle processes: https://github.com/open-telemetry/opentelemetry-js-contrib/blob/main/CONTRIBUTING.md#component-lifecycle

[github-actions]

👋 This issue has been marked as stale because it has been open with no activity. You can: comment on the issue or remove the stale label to hold stale off for a while, add the keep label to hold stale off permanently, or do nothing. If you do nothing this issue will be closed eventually by the stale bot.

[thompson-tomo]

I would propose we tackle #1961 before removing that way we can remove the source code but still have the published gem pointing to the version of the code used which has the deprecation notice added in #1963

[thompson-tomo]

Just an update, with #1963 the deprecation notice was added.
I have proposed in #1984 to update the source urls in the gems to link to the commit and with that a deprecation release could occur followed by the removal.

[Karan-05]

Hi all, I’d like to handle the ruby-kafka archival.

Plan:

1. Add the final deprecation notice + version bump in instrumentation/ruby_kafka/README.md and its .gemspec, then tag the release so the published gem points at the commit referenced in feat: Add commit id into source code url of gem metadata #1984.
2. Remove ruby-kafka from the instrumentation/all gem (Gemfile, .gemspec, loader) and from any release automation so it no longer ships with all.
3. Move the source into an instrumentation/archive/ruby_kafka folder (following the component-lifecycle guidance), leaving docs/tests there for reference, and update instrumentation/README.md plus CONTRIBUTING to describe the archive.

Questions:

• Would you prefer we keep the gemspec in-tree but stop releasing, or fully move it under archive/?
• After the deprecation release, should we keep the published gem pointing to that commit via the new metadata from feat: Add commit id into source code url of gem metadata #1984, or is there another archive process I should follow?

Thanks!

[thompson-tomo]

Part of the purpose of adding the commit to the source url metadata was to enable the deletion of the files. Note the commit id is computed at build time hence there is never any need to be changing it.

[Karan-05]

Thanks @thompson-tomo, that makes sense. I’ve archived the instrumentation under instrumentation/archive/ruby_kafka and left the gem metadata pointing at the tree so the published versions still resolve to the old commit. Nothing extra needed on the metadata front—appreciate the clarification!

[thompson-tomo]

Hmm, I think your pr is a little too early. We first need the source url pr merged, then we can do the deprecation releases and only after that do we do the removal/archival. See #1769 (comment)