hussein-awala commented on code in PR #30359: URL: https://github.com/apache/airflow/pull/30359#discussion_r1152527462
########## README.md: ########## @@ -473,6 +477,38 @@ of the contributors to perform the cherry-picks and carry-on testing of the olde The availability of stakeholder that can manage "service-oriented" maintenance and agrees to such a responsibility, will also drive our willingness to accept future, new providers to become community managed. +### Suspending releases for providers + +In case a provider is found to require old dependencies that are not compatible with upcoming versions of +the Apache Airflow or with newer dependencies required by other providers, the provider's release +process can be suspended. + +This means: + +* The provider's status is set to "suspended" +* No new releases of the provider will be made until the problem with dependencies is solved +* Sources of the provider remain in the repository for now (in the future we might add process to remove them) Review Comment: > in the future we might add process to remove them IMHO this could complicate the process to solve the dependencies problem, except if we wait for a reasonable period (ex 2-3 minor versions for Airflow) without any reactivity from the dependencies maintainers. ########## README.md: ########## @@ -473,6 +477,38 @@ of the contributors to perform the cherry-picks and carry-on testing of the olde The availability of stakeholder that can manage "service-oriented" maintenance and agrees to such a responsibility, will also drive our willingness to accept future, new providers to become community managed. +### Suspending releases for providers + +In case a provider is found to require old dependencies that are not compatible with upcoming versions of +the Apache Airflow or with newer dependencies required by other providers, the provider's release +process can be suspended. + +This means: + +* The provider's status is set to "suspended" +* No new releases of the provider will be made until the problem with dependencies is solved +* Sources of the provider remain in the repository for now (in the future we might add process to remove them) +* No new changes will be accepted for the provider (other than the ones that fix the dependencies) +* The provider will be removed from the list of Apache Airflow extras in the next minor/major release + (2.7.0, 2.8.0, 3.0.0 etc.) +* Tests of the provider will not be run on our CI (in main branch) +* Dependencies of the provider will not be installed in our main branch CI image nor included in constraints +* We can still decide to apply security fixes to released providers - by adding fixes to the main branch + but cherry-picking, testing and releasing them in the patch-level branch of the provider similar to the + mixed governance model described above. + +The suspension might be triggered by any committer, providing that: + +* The maintainers of dependencies of the provider are notified about the issue and are given a reasonable + time to resolve it (at least 1 week) Review Comment: I wonder if we can find a method to early detect the dependencies which could block the providers release (for ex two major versions older than the latest version), in this case we can create warn issues and invite the maintainers of dependencies of the provider to update its dependencies. ########## README.md: ########## @@ -473,6 +477,38 @@ of the contributors to perform the cherry-picks and carry-on testing of the olde The availability of stakeholder that can manage "service-oriented" maintenance and agrees to such a responsibility, will also drive our willingness to accept future, new providers to become community managed. +### Suspending releases for providers + +In case a provider is found to require old dependencies that are not compatible with upcoming versions of +the Apache Airflow or with newer dependencies required by other providers, the provider's release +process can be suspended. + +This means: + +* The provider's status is set to "suspended" +* No new releases of the provider will be made until the problem with dependencies is solved +* Sources of the provider remain in the repository for now (in the future we might add process to remove them) +* No new changes will be accepted for the provider (other than the ones that fix the dependencies) +* The provider will be removed from the list of Apache Airflow extras in the next minor/major release + (2.7.0, 2.8.0, 3.0.0 etc.) +* Tests of the provider will not be run on our CI (in main branch) +* Dependencies of the provider will not be installed in our main branch CI image nor included in constraints +* We can still decide to apply security fixes to released providers - by adding fixes to the main branch + but cherry-picking, testing and releasing them in the patch-level branch of the provider similar to the + mixed governance model described above. + +The suspension might be triggered by any committer, providing that: + +* The maintainers of dependencies of the provider are notified about the issue and are given a reasonable + time to resolve it (at least 1 week) +* Other options to resolve the issue have been exhausted and there are good reasons for upgrading + the old dependencies in question +* Explanation, why we need to suspend the provider is stated in a public discussion in the devlist. Followed + by LAZY CONSENSUS or VOTE (with the majority of the committers agreeing that we should suspend the provider) + +The suspension will be lifted when the dependencies of the provider are made compatible with the Apache Review Comment: I agree with @potiuk > I think it is a bit unfair if we call it "suspension" where it might be a "removal" - and the "come back" should be guaranteed when the conditions are fulfilled. Also, it may have side effects on other suspended providers, where maintainers will be discouraged to avoid wasting time fixing dependencies at the risk of not taking their changes. IMO we need to be clear on this, the suspension will be lifted once the providers dependencies are up to date. -- 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]
