dstandish commented on code in PR #30359:
URL: https://github.com/apache/airflow/pull/30359#discussion_r1152358707
##########
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)
Review Comment:
```suggestion
by LAZY CONSENSUS or VOTE (with the majority of the voters agreeing that
we should suspend the provider)
```
i think majority of committers means you require at least half of all
commiters to vote in favor!
##########
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)
Review Comment:
```suggestion
by LAZY CONSENSUS or VOTE (with the majority of the voters agreeing that
we should suspend the provider)
```
i think majority of committers means you require at least half of all
commiters to vote in favor!
--
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]
