>Just wondering, is it even fulfilling the criteria of incubation? I believe, the world does not need "active development in log4j 1.x" nowadays. What everybody needs from log4j 1.x is to fix security issues, fix outstanding issues (if any), keep the project buildable (e.g. avoid using outdated build systems), etc.
>it doesn't seem that sustainability is proven. The problem is log4j 1.x is like COBOL of logging. There are apps that are just stuck with log4j 1.x. The proof of sustainability is that lots of existing apps will never upgrade to 2.x because 2.x is incompatible. If the compatibility layer of 2.x would be improved to handle 99.999% of apps, then we could indeed move 1.x to the attic. The Incubator Cookbook says: >The ASF provides software for the public good, As I described, log4j 2.x is not a direct replacement for log4j 1.x, and there are **lots** of applications that can't easily be upgraded to 2.x due to testing, configuration, and implementation issues. The current Logging PMC is focused on log4j 2.x only, and they have no desire to release 1.x >active development but focus only on CVE fixes I would say, the primary goal of resurrecting 1.x is to focus on CVEs, and keep the project buildable and testable. However, it might be the case, that certain fixes or features would appear. The sad story is that the industry is using 1.x A LOT, and what Logging PMC did was they ignored the community, and they just stopped maintaining 1.x and focused on an incompatible 2.x Not only do they stop maintaining 1.x, but they also deny others to pick up the maintenance task. What I am trying to do now is to pick up that maintenance activity. Vladimir
