Hello Airflow community, How do we feel about removing the Qubole provider completely (leaving only old releases in PyPI?
On September 1 2023 ( https://lists.apache.org/thread/p394d7w7gc7lz61g7qdthl96bc9kprxh) the Qubole operator ws suspended. Due to the reasons described in the thread (Qubole got acquired and the service is generally abandoned) there is pretty much no chance for it to be resumed. I'd love to remove it completely and introduce a process where we can do similar things in the future for other providers if we decide to do so. I checked in the Attic project in the ASF (this is where abandoned project of the ASF get moved to) and it seems that just removing part of the project that has an active PMC is not going through attic https://issues.apache.org/jira/browse/ATTIC-218 . We are free to define our rules for that and I would like to use the opportunity to hash it out and propose a process (similarly to suspension) and criteria to remove providers from being maintained by us. It's more than suspension. We will completely stop updating the related code (right now some automated changes can still be applied and suspended providers can be resumed with simple PR). I would like to have the "next" step after "suspending" - removal. Roughly - we send PROPOSAL followed by VOTE (or immediately VOTE in obvious cases) with justification, PMC members only have the binding votes (similar as for releases). Only git history will remain - all the rest will be removed (including extra) - no traces of the provider remain in the next MINOR release (2.8.0 in the case of Quibole). The provider will still be in PyPI and historical releases will be in https://archive.apache.org . If someone would like to bring back such a provider, It should go through the same process as a new provider (voting/consensus). And we might reject it. WDYT? Any comments for such an approach / process ? J.
