potiuk commented on code in PR #34369: URL: https://github.com/apache/airflow/pull/34369#discussion_r1327087265
########## airflow/providers/google/cloud/transfers/gcs_to_samba.py: ########## Review Comment: > For me the most important thing is user comfort. Where users are likely to look for this integration. It should be simple and clear. We should not have completed rules. I am not sure how we assess that it's neither simple nor clear and it refers to very subjective assesment of "where the user will look for something when there are two ends". I am not sure where users will be likely to look for this integration - in GCP ? in Samba?. No idea. When the user wants to use 5-10 GCS releated transfers, they will look in 'google". When the user only has samba and wants to look for all the possible ways Samba can interact with external world, they will look in Samba. But most likely the user will look for 'How should I move from GCS To Samba or from Samba to GCS" and will look in both. But regardless, if we are looking to help users to find something, maybe better solution will be to have a simple search on our website that will let them find it. The attempts to foresee in which directories/indexes people will search for something was simply not working - simple search where you enter something you look for is better. Yahoo and Altavista story vs. Google have proven that for a long time. I think generally no-one looks for things by traversing tree-like-hierarchical indexes. That's why in this case I think optimising for maintenance is better then optimising for (doubtful) search convenience. But maybe I am wrong of course. There is no "good" solution for transfer operators. There are only trade-offs. And I think maintenance likelihood as an optimisation goal is good one. > I do think that we should finalize the policy around this cases. The blury rules make it so that we are challanging the policy with every PR. I would not exaggerate, It's Just a few PRs. And mostly the two of us argue about it :) > The shared goverance model does not bind google stackholders to contribute only to goolge provider. They can have intrest also in other providers. Not at all. It's quantum more than 0/1 logic. It's all about higher change of being interested in making it works. > If Samba provider will not work then the google integration wont work regardless of where the class is located. Not really. Samba in this case is an optional feature of google provider (it will be a [samba] extra) and until you import this particular class it won't even import samba classes. > I'd be happy to start a mailing list thread after the summit. Sure. No problems. But I think it's just wrong optimisation goal. Also before you send it - I suggest you make a complete proposal and see what you come up with - i.e. take the transfers we have and map them according to rules you propose. You might be surprised how "unobvious" this will look. But yeah. I might be wrong of course. -- 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]
