gsemet commented on issue #10523: URL: https://github.com/apache/airflow/issues/10523#issuecomment-684614478
Hello everybody, I am the original maintainer of [stable/airflow](https://github.com/helm/charts/tree/master/stable/airflow), along with @thesuperzapper. I just wanted to add some points, especially on how we would like to handle the transition. ## 1. stable/airflow Chart "donation" There are two points heres: - is it possible? - is it wanted? ### 1.1 Is it possible to donate state/airflow? About the chart donation of "stable/airflow" to the ASF, I of course do not have any problem and I guess most contributors won't neither, but on a pure legal point, I guess we would need approval of all contributors to the chart, of see with the Kubernetes legal team if this is even possible (there were no CLA signed, so the ownership is still "shared"). This is a community effort, and legal side might be tricky to deal with. That said... ### 1.2 Is it even wanted? I also understand the Airflow teams might not actually want the chart because it is (a little bit) opinionated, originally based on an another chart, it has "history" behind it, lot of features, etc. I can fully understand that, and of course if a migration guide can be written we will fully back it. But I see some drawback here: - migration might not be easy for users - featureset might not be as close as wanted by most users - I really hate when a project suddently disapear without a migration path, letting *me* control when I want to do the migration, I guess other users feel the same. - we have the november deadline ## 2. Backward compatibility My original thought was to have 2 charts, the 'stable/airflow' that would kind of be frozen or slowed down in it evolution and would die slowly in favor of the official airflow chart, and with the help of the community, the official chart will increase its featureset and replace naturally stable/airflow. But with the november deadline, I would be sad to let users without any soft migration path (ie just change the repository and it continues to work until they are ready to invest time and effort into migrating to the official chart). My opinion is that 'stable/airflow' should continue to live somewhere after the november deadline, ideally at Airflow, but I understand that might cause problem. We will probably create a dedidacated group on github and see if we can redo the CI in Github Actions... For the name, "airflow-chart-contrib"? "airflow-chart-community" ? So there would be 2 charts: - "stable/airflow" at a new location - "airflow/chart" Each one pointing to the other, with a clear explanation that which is the official chart and other is the community driven chart that is ultimately meant to be superseeded. ## 3. Review Process incompatibility On the approval process itself, "stable/airflow" is really a product of the community. There is no roadmap. We strongly rely on the CI and the automatic checks and does an amazing job. I am actually surprised to see such a high level of contributions, most of the time I simply approve because the patch is great, the documentation is updated and even the migration section is well done. (Ex: https://github.com/helm/charts/pull/23651, thanks @thesuperzapper !) So I feel that the heavy/strong process Airflow project will not be compatible with the way this chart has been developed until now. I started it because I needed some features, and most of the features added later had been so by the community (I have not even tested all of these features!). But that's the role of well respecting the versioning contract (minor/major/bugfix) and having a powerful community (and the contributors to my chart has been very well educated and did very good code AND documentation), so now we have a feature-packed chart that is really stable and used in production, that evolved sometimes rapidly and things broke from time to time, but at the end, and it is very solid (that's my opinion :D ) I do not have any install statistics, would love to get some numbers. ## 4. Solutions? Apart from the initialization scripts and some minor points, I do not see major blockers that would prevent users from switching from 'stable/airflow' to 'airflow/chart' when the migration guide will be ready and when the user is willing to. We are already using the airflow docker image. Like I said, if Airflow would accept this "light" review process on this non-official charts but that would be still located under the Airflow umbrella for a time after november, that would be great for everyone. The other solution is we move to our own unofficial github group but that would still introduce ambiguity, I guess lot of forks will happen, users won't have a clear path to the new path of the "official-unofficial chart"... Of course a migration guide to the official chart would be constructed over time, and with the help of the community, this should be feasible. I would like to avoid an "hard die" of 'stable/airflow', I would really like to see a "slow but controlled die" of the chart. On the Airflow side, I would like to request its charts/documentation to clearly explain what it does differently from stable/airflow, and points to its new location after november 3rd so that existing user can still use it. Since we do not have any "homepage", I guess most users will try to find the Kubernetes chart for Airflow at Airflow... again, moving 'stable/airflow' under airflow (example: https://github.com/apache/airflow-legacy-chart) and let it die here would be ideal for us and the existing user base. My little finger tells me that is won't "died" instantaneously so there will be some contributions, even new features, so its versions will continue to increase but that would be still done like today, by the community. Naturally, users will switch to the official chart if it is mature enough *when they want to* (that's very important for me, philosophically speaking) and then, later we can shut down 'stable/airflow' completely. These are my opinions, I hope it will help this discussion. ---------------------------------------------------------------- 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]
