Before any Pull Requests are reviewed this discussion needs to come to a conclusion.
So far I have seen some people in favor of option 1, none in favor of option 2, none in favor of option 3, some in favor of option 1 or option 4, no one in favor of option 5 (with several -1s) and Vladimir who seems to be in favor of option 5 + more (whatever that may be). Other than Vladimir and Leo I am not sure who the other contributors are and am still awaiting input from them. In the meantime, we are still fighting fires in the Log4j 2 world and really have limited time to review these PRs right now anyway. Ralph > On Dec 25, 2021, at 2:59 AM, Andrew Marlow <marlow.age...@gmail.com> wrote: > > this is a great summary of the options. I vote for option 2. > > On Fri, 24 Dec 2021 at 16:47, Ralph Goers <ralph.go...@dslextreme.com> > wrote: > >> As we all know Log4j 1.x reached end of life in August 2015. Log4j 1.2.17 >> was released on May 26, 2012. The last commit was to update the >> web site 7 years ago. The changes.xml file shows there were commits up to >> sometime in 2012, all of which were performed by Gary Gregory >> and Christian Grobmeier who ironically both voted no to opening the repo >> back up. >> >> The point of this history is to point out that the project essentially >> died in 2012. We simply acknowledged it in 2015. >> >> So now we have voted to open the repo. The question then becomes what to >> do next and going forward. I see several options: >> >> 1. Create a README.md that publishes the projects EOL status and do >> nothing else. >> 2. Create a README.md that says the project is EOL and no further big >> fixes or enhancements will be made but 1.2.18 was a special >> circumstance. Perform ONLY the following work for 1.2.18: >> a. Make the build work with a modern version of Maven. >> b. Fix the Java version bug. >> c. Fix CVE-2021-4104 (expanded to address all JNDI components) >> d. Fix CVE-2019-17571 >> The expectation is that the above would address the actual issues and >> not just remove classes. >> Do NOT perform a release of any kind. >> 3. Option 2 but only perform a source release. >> 4. Option 2 but perform a full release. >> 5. Option 4 but allow development to continue, including bug fixes and >> enhancements. >> >> I personally can see valid reasons to do any of the above. I have my own >> opinion on this but I will post that in a reply to this discussion kickoff. >> >> If you have other proposals feel free to state them. >> >> This discussion will be followed up by a vote thread if necessary. >> >> Ralph >> >> >> > > -- > Regards, > > Andrew Marlow > http://www.andrewpetermarlow.co.uk
