scottrigby commented on issue #10523: URL: https://github.com/apache/airflow/issues/10523#issuecomment-683735671
@potiuk airflow voting processes make sense. Just a few quick replies: - donation: the entire `helm/charts` project - this includes each chart there - is already licensed under an Apache License 2.0: https://github.com/helm/charts/blob/master/LICENSE, by The Helm Authors. We've already stated our interest in donating charts(s) sources to distributed repos, with a preference for maintainers of the software a chart is installing. So you're good on that side - That said, we understand the app maintainers may not wish to take on maintenance and users for an existing chart, as you said. That part is up to the rules and see decision of each community, and I respect your decision if I understood correctly. It I want to make sure a few points are clear from our side, like the ownership question above, so you have the best information in order to make the decision. - The prometheus-community considered similar questions and decided to make a separate community repo and invite the contributors/maintainers of the stable prometheus charts continue to co-maintain them. Their process required a sponsor and vote - I understand your process is different, but could that be a good option for you? - splicing in the git history: do you mean it doesn't make sense to do so with the current chart in this git repo? If so I agree. The question is do you plan to make versioned packages of that chart available to end users via a Helm repo? From experience in a last company, I can tell you end users are already unclear about that. But if so, I agree an easy depreciation notice for the stable chart is for users to use the one you have here. - when a chart moves helm repos there must always be an upgrade path, but if the initial version in the new location changes only the Readme's install instructions, the upgrade path is usually as simple as adding the new repo and upgrading to the new chart path and version. However if the chart is structured differently, there's usually more burden on the end user for migrating. IIRC with Airflow what uses want to migrate are 1. DAGS and maybe 2. Run history? We can also simply say there is no migration path, but still point users here. Alternatively, as mentioned above, the Bitnami team hosts and maintains an Airflow chart, and the depreciation notice from stable could point end users there instead. Do you have a preference? Thanks for your time and attention on this. ---------------------------------------------------------------- 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. For queries about this service, please contact Infrastructure at: [email protected]
