Re: [Log4j] Potential support/dev policy for plugins

[Piotr P. Karwasz]

Hi Matt,

On Tue, 11 Jun 2024 at 22:15, Matt Sicker  wrote:
> 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

I think this is a nice way to increase the transparency regarding the
support level of official Log4j components and the rules on the
inclusion of new components.

We already did a great job of removing from Log4j 3 the modules that
are hardly used[1] or have many bugs that we have no time to address.
However:

* some modules in Log4j 3 are there, because "my employer uses it". It
would be nice to convert them to "my employer supports it": if the
component breaks or has some bugs, it would be nice to have an
official/semi-official statement that somebody will fix it.
* some modules (e.g. Cassandra or Kafka) are used by users. We could
restore them in 3.x if we are confident that someone with experience
with those libraries will help us fix the problems[2].
* some third-party modules could be included in the future in Log4j.
We should draft a set of conditions on which modules are eligible.

Piotr

[1] In my personal experience, the best code in the world can become a
minefield of bugs if it is not used.
[2] For me it means they use Cassandra and Kafka on a daily basis.
Past experience with a library can become obsolete very fast.

Re: [Log4j] Potential support/dev policy for plugins

[Christian Grobmeier]

+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