potiuk commented on code in PR #34369: URL: https://github.com/apache/airflow/pull/34369#discussion_r1326930253
########## airflow/providers/google/cloud/transfers/gcs_to_samba.py: ########## Review Comment: > some might disagree but I would claim that samba is the higher intrest provider here I'd disagree actually :) It's a bit blurry of course, but I think our rules are rather clear that the "target" STAKEHOLDER interest is what matters when we make the decision. But in order to have the interest, it would have have to have a stakeholder. This is mainly the question of "who will likely want to maintain the transfer operator because they want your data in". With services like GCP/AWS -> it's very clear who the stakeholder is and why they are interested in having transfers to them. For example if you derive a new compression and make it faster to upload something to GCS, it's clear that Google team will be interested in adding the option to use it. With SAMBA it's much less clear who the stakeholder is. Samba is a program that implements CIFS protocol https://www.samba.org/samba/docs/using_samba/ch01.html - it's not a service. Those who release samba are not interested in getting the data from GCS. They are indifferent about that to be honest. When you use GCS to SAMBA, the other end of the transfer is ... YOU - the user who has a Windows network drive. So what happens in this case when you have GCS -> SAMBA you only have one stakeholder (Google Cloud). The other stakeholder is missing. We have a number of similar cases (for example GCSToLocalFilesystemOperator) which is placed in Google provider. This is a very similar story. I think this one should also be in `google` provider. -- 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]
