shubham22 commented on code in PR #24680: URL: https://github.com/apache/airflow/pull/24680#discussion_r910348778
########## 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: I am curious about a few things here - 1. What would be the process for selecting these contributors? Would we ask the contributors to share detailed result of their testing (system tests) to confirm their claims? 2. Would this selection of contributors happen before every release? I am guessing, yes. ########## 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. Review Comment: Should we describe here that "mixed governance" model is opt-in for a provider? I am guessing this model will be followed only if there are stakeholders (or contributors) who are taking the responsibility to perform the cherry-picks and test them thoroughly. ########## 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: minor suggestion - "while the responsibility of deciding cherry-picks for the older branches of a provider is on those who take ownership to maintain and test the cherry-picks against older versions of the given provider." -- 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]
