Hi Matt, On Tue, 11 Jun 2024 at 22:15, Matt Sicker <m...@musigma.org> 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.
