potiuk edited a comment on issue #19250: URL: https://github.com/apache/airflow/issues/19250#issuecomment-954080195
> In essence, this approach does not change the strategy of using DAG, but it can give some users who do not have git repository another choice to deploy on the cloud. This is all fine and I agree with giving people more options. I do not argue with that (actually - I do not even argue at all- i ask others in the community for opinion and present my own). However there is a huge difference how the options for the user are provided; 1) if it is provided as ecosystem/external - the person/organisation who provides it provides all the support, user questions, solving problems. customisations 2) if it is provided by the Apache Airflow Communtiy - it is the community that provides the support, release working software, fixes problems and generally supports the users. Both are viable options. Both has happened in the past for various parts of Airflow (and various ecosystem components). There is no "one is better than the other" - they simply have different characteristics. And sometimes even those who provide the "option" or "alternatives" keep it as "ecosystem" part becaus then they want to keep their own pace of changes and develop it futther (example - user-community chart). For the Apache Airflow community - following the Apache Way http://www.apache.org/theapacheway/ - any new option like that to support makes more combinations to test, develop and make sure it works fine for the users. That's why anything that we accept as contribution MUST at least have automated tests, and we have to be sure it brings value that offsets the cost connected with maintaining it. Also when software brings dependencies we must be sure we are ok with the dependencies - licence wise, stabiity wise, future-compatibility and maintenance wise. In this particular case Quarkus (which I first hear of) is a Java-based dependency which we have almost no experience with as a comunity. Any fixes/problems there **might** require skills that are a bit outside of our domain. I do not know if those are serious problems or and blockers or not - I am just pointing out the areas that are potentially problematic, and that such "Add new option for users" might have some serious implications that we should consider. Accepting a "feature" or "code" is more often than you think "liability" rather than "asset". I am not telling it's the case here, Certainly if we go in this direction, comprehensive set of unit tests is absolute MUST - without it, it is "no-go" no matter what. So I think we should wait for others to chime-in (but it might take days or weeks depending on how busy they are) - so crertainly do not expect immediate actions here. -- 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]
