Thank you to everyone involved, and especially to Adheip! This proposal makes sense 100%,
I also want to propose that a separate VOTE would be held to invite the current main contributor and maintainer of Druid-operator (Adheip) to the Apache Druid list of committers. This will reflect the size and significance of the contribution, as well as assist with continuity. Best regards, Eyal Yurman On Thu, Sep 25, 2025 at 1:42 PM Adheip Singh Sadhrao <[email protected]> wrote: > Thank you for initiating this discussion on the Druid Operator release > strategy. > > I strongly believe decoupling the release cycles and moving to a separate > repository (apache/druid-operator) would be the most appropriate approach. > The Druid Operator is fundamentally version-agnostic - a single operator > version can deploy and manage multiple Druid versions from 16.0.0 through > 25.0.0 and beyond. Its releases are driven by operator codebase changes, > Helm chart updates, and Kubernetes dependency updates (controller-runtime, > api-machinery) rather than Druid releases. > > The Kubernetes ecosystem has specific distribution requirements that differ > from traditional Apache source releases. Users expect to deploy operators > via Helm repositories using standard commands like helm repo add and helm > install, and the operator requires published container images to function. > Without these distribution mechanisms, even with code in the Apache Druid > repository, the operator would be effectively unusable for the Kubernetes > community who rely on Helm and container registries rather than source > builds. > > I recommend moving the Druid Operator to its own repository after the > initial merge, establishing independent VOTE procedures, and setting up > proper Kubernetes distribution channels including a Helm repository and > container registry. This separation would best serve both communities while > respecting their different release requirements and distribution models. > > Could you clarify what the process is for requesting a separate Apache > repository and whether this requires a VOTE? Also, does Apache have > existing infrastructure for hosting Helm charts and container images that > could be leveraged? >
