potiuk commented on PR #43453: URL: https://github.com/apache/airflow/pull/43453#issuecomment-2470090708
> @potiuk Sure, we get this point, but that's exactly the reason why we had doubts about the best way to move forward. It's just a single-line change, but - breaking change. And the fact we expect the Operator to behave differently doesn't mean it's the same for other users, maybe for most of them the existing behaviour was actually fine? > That's why we wanted to ensure first there was a common agreement to change the logic, but if there is no direct ownership of the Operator - then I believe we should be even more cautious about introducing breaking changes, which could be avoided for example in one of the above ways: Yeah - and that's where seeing test helps and - as you see there were people who looked at it and said "yes, looks fine, let's merge it'. We have 4000+ operators in Airflow. There is no way we can be authoritative in all of them as maintainers. But you already said you feel that you would like to discuss it with `dbt` people so if you have another proposal after talking to them that will result in a new PR, that's cool. And if you care about this dbt operator and want to make it better - this is how you become "steward" of it, by making it better and fix problems - we as maintiners are super happy if people lile you care and want to make things better (and also take mnre responsibility for making decisions there without having official authority). This is precisely how you might become committer here - by making decisions and implementing them and taking responsibility for them (including fixing problems when people raise them). And there are a number of places in Airflow that ha ve their own "informal" stewards like that. And those people - when they are active in several parts of the code and are engaged, might then later be invited as committers. This is how it works here - committer (also known as maintainer) is not a person who is "responsible" for some part of the code - this is a person who is committed and engaged in the project, but besides of being able to approve and merge the code that "looks good" and that author is confident about fixing some problems and confirming they tested it, they have no "authority" / "responsibilty" to make decisions over specific part of the code. Yes. I know it's surprising that it works, but it does. Because authors like you take more responsibility for their own decisions when their code is merged and their name is attached to "I made that change and vouch for it". The code looks good, we cannot see any big issue and we trust you care and made good decision. Worst thing that can happen, people will downgrade the provider and we will have to revert that change if it will turn it has more problems that we foresaw by reviewing them as maintainers, no big harm done - but we trust you will test it with release candidate as well and confirm it's working. -- 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]
