Having a separate GitHub repository and release cycle sounds like a good approach. It doesn't require a vote to create a new GitHub repository, we just need to request one from Infra. The releases themselves will need to be voted on, and there will need to be official source releases. The source releases will need to include Apache compliant LICENSE, NOTICE, etc, and generally comply with https://www.apache.org/legal/release-policy.html (search on that page for "MUST" to see the most important requirements).
The best way to sort it all out is to actually do an Apache release: meaning, prepare a compliant source package, do a VOTE, and release it through Apache distribution servers. Someone should volunteer to do this. The Druid PMC can provide guidance throughout the process. It would be best to do it as soon as possible, without waiting for the natural "next release" time for the Druid Operator. As to hosting charts, is any infra needed beyond a static web site? I searched around a bit for Helm charts for other Apache projects, and one I found was for Airflow: https://airflow.apache.org/docs/helm-chart/stable/index.html. It suggests using the project website itself as the helm repo (https://airflow.apache.org). I suppose it works because there is this index.yaml file: https://airflow.apache.org/index.yaml. To me it seems odd to put it at the root, but maybe we could do something similar at like https://druid.apache.org/helm/. As to hosting container images, would it work to use the official Apache ones hosted on Docker Hub? https://hub.docker.com/r/apache/druid/ Gian On 2025/09/25 20:02:15 Adheip Singh Sadhrao 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? > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
