I suggest also removing it from pypi for security reasons. If there is a 
security issue with it then the issue will remain with us.

B.

Sent from my iPhone

> On 26 Oct 2023, at 20:20, Jarek Potiuk <ja...@potiuk.com> wrote:
> 
> 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.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@airflow.apache.org
For additional commands, e-mail: dev-h...@airflow.apache.org

Reply via email to