villebro commented on issue #31408: URL: https://github.com/apache/superset/issues/31408#issuecomment-2578829759
> Probably fine to use https://github.com/apache-superset/ org for this, that way you get admin rights and we don't have to consider this tool/repo as an ASF-sanctioned thing that provides all the ASF-related-type constrainst & guarantees @mistercrunch I've carefully considered the ASF vs non-ASF repo option, and here's some further thoughts: - For scripts and other general recipes like a Helm chart, which are easy to audit, hosting on a non-ASF repo should be fine. However, a Golang based operator, with a complex build process that results in a Docker image, will not be easy to audit before use. - While the ASF doesn't explicitly stamp Docker images or other convenience releases, the battle tested constraints & guarantees that are imposed by the ASF on their repos will provide an added layer of security for ensuring that the built and released artifacts are legit, and have met the strict requirements of the ASF. - Kubernetes operators are deployed on highly critical infrastructure, and are able to both provision and destroy resources not only on the Kubernetes cluster, but even outside the cluster (e.g. load balancers via Ingress/Gateway resources). For this reason, many orgs may have security and IPR policies preventing them from deploying OSS operators that originate from non-ASF sanctioned repos. - The ASF already has a number of actively maintained [operator repos](https://github.com/search?q=org%3Aapache+operator&type=repositories) for top ASF projects. This implies that this is a typical pattern for ASF projects, and will likely not receive pushback from the ASF. For the reasons listed above I maintain my recommendation of hosting the operator on the ASF GitHub org. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
