potiuk commented on code in PR #24680: URL: https://github.com/apache/airflow/pull/24680#discussion_r910416403
########## 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 +branches. + +The "mixed governance" means that: + +* The Airflow Community and release manager decide when to release those providers. + This is fully managed by the community and the usual release-management process following the + [Apache Software Foundation release policy](https://www.apache.org/legal/release-policy.html) +* The contributors (who might or might not be direct stakeholders in the provider) will carry the burden + of cherry-picking and testing the older versions of providers. Review Comment: 1. Just the usual in OSS - if someone wants it, they raise a PR or open issue. I want to describe it in details when we start doing it (we need to verify the process) - but I think. as usual anyone when their (or other's) PR gets merged might raise their hand and comment "hey - I want to cherry-pick this and other changes and test it for this and that version and I would like to get a branch I could reise resulting PR against. As usual in oss - if you want something to happen - take a lead and start doing it. That will also naturally filter the people who would "like" to have it but they would expect it will "magicallly happen". If you do, it , raise a good PR and cherry-pick all changes and confirm you tested the result of your PR and this is the 2nd provider version (not 3rd or 4th), this is fine. And anyone other can cherry-pick more PRS as well. No limits there - but someone must volunteer and commit to making it ready for releas to make it happen. 2. No selection. Actions by those people will decide (unless there will be conflicting requests which we can handle when they happen). for now I optimistically assume that there will be a lot of people who would "want" tbis to happen, there will be very few who will "make it happen" and there will be no conflicts. And we handle similar conflidcts on a daily basis when for example 2 people contribute the same bugfix or feature. It's far easier to manage it when it happens than to make a process to make sure it does not happen. -- 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: commits-unsubscr...@airflow.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
