potiuk commented on PR #43453: URL: https://github.com/apache/airflow/pull/43453#issuecomment-2457729170
> I don't see any value in writing unit tests before there's confirmation the approach is fine, otherwise it's just a waste of time of contributors. You start with design, not with coding (that's why the confirmation should happen first in the issue anyway, the PR was opened because you asked for it), and the reasoning is described in both the issue and MR description. It's more than enough to provide a feedback if it makes sense conceptually for someone familiar with given provider, especially in a situation when a few potential solutions were proposed. Yes. You trade the time of contributors with time of maintainers. And no. It's not a general "truth" that things start from design. There is an idea of "emerging design" that comes from discussion on a code implemented and tests showing how it work. There is even "test driven development" so statement suggesting that there is the only way of doing things starting with design is totally unfounded. And here we prefer to see the code and tests to be able to assess the impact - that saves precious time of maitainers who (I am sure you can attempt to empathise wiht them) sometimes review 10s of PRs a day and do it in their free, voluntary time. So the best thin you can do is to follow the way we do it here. If we follow things each of 3000+ contributors think is "better" , that would make it impossible to manage the flow of incoming contributions. So if you would like to join 3000 contributors, I think it makes sense that you adapt to the way how they work, not the other way round. Or at least that seems more reasonable from common sense point of view. > But there has to be someone responsible for the provider, who knows its specifics and who takes the final decision - I guess you don't merge PRs related to providers you don't know just because they seem to be documented and tested, you have to understand the impact. No. This is how things work in corporate-driven projects. This is not how things work in an open-source projects governed by the Apache Software Foundation. There is no-one responsible for this particular piece. You can see the history of contributors by following git history of the files you modified ``` git log --follow providers/src/airflow/providers/dbt/cloud/operators/dbt.py ``` And see if there are changes relevant to your and ping those contributors if you think their opinion is relevant, but list of all contributors is all that you can see this way. We merge changes if the author (and reviewers who might or might not be maintainers) convince us that they tested the change and review looks good. Also when we release such a change, that is merged the authors are asked to check release candidates to confirm that their change worked as expected and that they tested it - see for example here https://github.com/apache/airflow/issues/43615. And we can always revert or fix it when you find it's not during your testing, and produce rc2 etc. So ultimately it's actually your responsibility as an author to test and "convince" maintainers that the change is tested enough and to test it when release candidate is sent for voting . This is why also we ask you to add unit tests, to get more confidence that you understand the process and you are going to follow it - including testing the relese. We treat contributors very seriously 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]
