+1 Sounds like a good thing. Being in the top 8% of most critical open source projects requires us to consider everything very carefully
I also see that we need to adopt the Airflow requirements to us a bit, but they are indeed a very good start -- The Apache Software Foundation V.P., Data Privacy On Tue, Jun 11, 2024, at 22:14, Matt Sicker wrote: > I spoke with Jarek at Community Over Code Conference EU last week about > an interesting policy Airflow uses to manage their ecosystem of > providers. [1] In short, they have policies for accepting, maintaining, > and removing providers based on various constraints. The general > approach seems like a good inspiration for how to potentially handle > acceptance and removal of plugins. For example, integrations with OSS > projects require appropriate integration tests that can spin up the > underlying software being integrated with. For integrations with > proprietary services, the service provider has to maintain a test suite > along with publishing test statistics and such to stay valid. When > providers (or plugins in our case) start to fail tests or similar > problems, if they’re not fixed by the contributors or experts from the > community, then the provider is disabled in future releases until > someone fixes them. > > While I think we can adapt the Airflow guidance to Log4j, we will > likely have some different requirements. I think this would help a lot > in determining when and for how long to support plugins that involve > third party dependencies. > > [1]: https://github.com/apache/airflow/blob/main/PROVIDERS.rst
