potiuk commented on PR #35861: URL: https://github.com/apache/airflow/pull/35861#issuecomment-1829761337
> > I see no problem with that. Mssql is considered experimental. We can publish it under statement of best effort. In the mailing list thread one of the comments was that we should provide tooling to ease migration for users. That means the tool/script is mantained and released by Airflow. I don't think it matters where the script saved (from user point of view). I think we never said we will maintain and relase the scripts. We discussed - we should tell the users how to do it, but not that it will become part of standard airflow tooling and that we will keep it maintained. Let me explain why I think it should be in a separate repo. I personaly think we should never have the code in our main airlfow repo that we are not planning to update dependencies on regularly. This opens up for example for CVE/security vulnerabilities. There are already CVE/vulnerabilities reported to us about the code that is just somewhere in our code when it is merely an "example". This basically means that we are supposed - to update to newer version of dependencies in the future, because some 3rd-party dependencies might have a security issue. For example if we add `requiremetns.txt` - even in a subfolder of the main airflow repo and we will say `sqlite==3.14.5` and a security fix is found in it, then (especially soon in the future) we will get some of our users scanning airflow repot and pointing out to us "you are using an outdated and insecure version of sqlite". And we at least will have to respond to those reports and explain, and most likely if more people will be complaining we will likely have to do something about it - publish VEX information stating "this is only a tool that we are not really maintaining with airflow any more". Having separate repo with very clear README and explanation what's the purpose of it, and information that this is only an example/one-time-conversion tool that users are going to use and modify on their own as needed makes it much less possible that such reports will be raised, especially if we just write a blog post about it at Airflow Publication in medium and won't link to it from our documentation. And it is quite fair I think as well from our side - we will provide a way for our users to migrate, but we wont commit to maintain it in the future. Which we can also clearly say - the longer you delay, the more "future" problems YOU will be dealing with - it's your choice - dear user. I think it's an assertive and fair way of communicating with our MSSQL users. The more explicitly we do it now, the more "separate" it is now from "airlfow" code, the easier (and fair) it will be to tell our users who will come to us 2 years from now telling that the migration script does not work that they are on their own, because they have not done what we advised. They had a chance to do it when our eyes and hands were on it, but 2 years later our eyes and hands will be looking elsewwhere. This is something that we have a bit of problem now - when we have the users that come to us 3 years after 1.10 reached end-of-life. They see our docs (if they look at it at all), they see released "migration check" and if does not work (for example because setuptools release broke it) they will come to us to "fix" it. We refuse, of coure, but I would like to have this migration efforts very clear that this is quite a bit their problem if they delay the migration and make it very, very clear from day one. I do not want to give users the impression we are going to support them 3 years from now when they come and say "this script does not work any more". -- 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]
