Leo>Instead of or in addition to some of those fixes I would suggest the following (in case you wonder, I might volunteer to do ALL of that, so don't assume I just sit and tell others how things should be done): 1. Use the existing repo https://github.com/apache/log4j instead of a newly created one. The existing repo is well-known in the community (108 watch, 537 forks, 849 stars), and it is very strange to drop all that. 2. Add GitHub CI so the code at least compiles. I think we should not fix everything like javadoc/site/whatever if it takes too much time. Having any CI would be way better than nothing. 3. Consider existing known CVE fixes (e.g. somewhere there was a mention of RedHat fixes for log4j 1.x CVEs). It might be easier to apply the fixes before the code is split. 4. Consider splitting the code into modules. In practice, there's already a branch that does exactly that: https://github.com/apache/log4j/tree/log4j12modules/modules 5. Release 1.2.18. 6. Treat CVEs. For instance, implement hardening in log4j-net or whatever. 7. Release 1.2.19 8.... see what happens, maybe new PR would appear.
Vladimir
