Thank you for this guidance Gian.

I created a couple of issues under the druid project for us to track and
tackle:

   - https://github.com/apache/druid/issues/18581
   - https://github.com/apache/druid/issues/18582

Between Adheip, Eyal, myself we should be able to move along quickly with
the bootstrapping of the project.

On Fri, Sep 26, 2025 at 7:21 AM Gian Merlino <[email protected]> wrote:

> 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]
>
>

Reply via email to