potiuk commented on code in PR #30359: URL: https://github.com/apache/airflow/pull/30359#discussion_r1152808160
########## 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. Yes. That's why we are not defining it (yet). I think removal of provider from our code should be much more deliberate and serious decisions will have to be made on simply removing the provider and moving it to "attic" (this is the term that the Apache Software Foundation uses) https://attic.apache.org/. And we are nowhere near (I think) to be close to a decision of doing so for any of our providers. As it works in the foundation Each PMC can release multiple "artifacts". Each "arifact" (Source package) can be moved separately to the Attic when the PMC decides in voting. This is an established process in the foundation to move the whole PMC to attic (https://attic.apache.org/process.html) - but I discussed it with the "elders" in the Foundation and we could move any of our artifacts to the Attic and follow the same principles. But - as I stated above - I think we are nowhere near to remove any of our artifacts to the Attic. I think if it happens that we will have a suspended provider for 2-3 months for example and we ping the maintainers of related dependencies and we don't find another solution to "resume" the provider, we might want to move it to the attic (but I think rather than deciding on the policy upfront, we might define the policy as we see it is needed. This is the usual approach we have here, we are aimging to be (both Foundation and airflow) rather light on policies and we rather wokr here in the way that we define the policy the first or even second time we have to deal with an issue (unless this is something we can foresee will impact our users if there is no clear policy). -- 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]
