potiuk commented on code in PR #24680: URL: https://github.com/apache/airflow/pull/24680#discussion_r910422822
########## README.md: ########## @@ -410,6 +410,47 @@ For example this means that by default we upgrade the minimum version of Airflow to 2.3.0 in the first Provider's release after 11th of October 2022 (11th of October 2021 is the date when the first `PATCHLEVEL` of 2.2 (2.2.0) has been released. +Providers are often connected with some stakeholders that are vitally interested in maintaining backwards +compatibilities in their integrations (for example cloud providers, or specific service providers). But, +we are also bound with the [Apache Software Foundation release policy](https://www.apache.org/legal/release-policy.html) +which describes who releases, and how to release the ASF software. The provider's governance model is something we name +"mixed governance" - where we follow the release policies, while the burden of maintaining and testing +the cherry-picked versions is on those who commit to perform the cherry-picks and make PRs to older Review Comment: Well. It's not the responsibility to decide. Maintainer decides if the PR is merged (as usual - no chang here). This is the "burden" - cherry-picking is not easy. This is mostly dirty, boring and ground work to be done, nothing really "cool". I've been doing it for years, so I know what I am talking about :). I want to be absolutely sure that this is well communicated. It's not a priviledge or ownership. This is committing to the hard work, without taking the ownership. The ownership and decision making stays with maintainers, but they want to spend as little time an energy as possible on doing it. The maintainer migth look at the PR and tell "this should not be cherry-picked" and it will not be merged. (this is how ASF rules work0. So summariising "responsibility to decide" and "ownership" are bad words in this context. BTW. One of the purposes here is to make it very clear, that it's not a burden of the maintainers to make and you have to REALLY want it to commit and to do it. And by doing it, you materialise your commitment to take the burden of it. There should be very few of those and only when there are really good reasons and a lot of effort put by those want to make it happen (just wanting is not envough). -- 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]
