I am in favor of option 1, basically this: * Add an EOL marker, big and bold * Allow the repository to be cloned * Allow the repository to be forked * Disable the creation of new pull requests (on github) * Disable creation of issues (on github; this is the default; I want to stress this by mentioning it explicitly)
My reasoning behind this is that an EOL must not consume resources. Any resource available should be invested in something that is not EOL so that opportunities are not lost with friction or distraction. Having this, someone can easily fork/clone the repository on github and work on the codebase. We may consider accepting these patches as contributions in the future. So long logging services considers log4j1 EOL, people should be strongly encouraged to migrate and not to base their work on an EOL component. Why not allow creation of pull requests or issues? This clearly draws a line. Logging services is not investing resources in an EOL component. This enforces that any new commits happen on a fork or clone. This has the effect that the public could not become confused. In the perception of the general public any changes are clearly unrelated to Apache logging services. The position of Apache logging services is clearly that the component is EOL. Should valuable contributions appear in the future we may reconsider what to do. We could then for instance review changes in a fork and cherry pick the contributions. This could hold for minimal changes that fix CVEs. If changes are too large to be cherry picked, my gut feeling tells me that too many resources are invested in an EOL component. -- Sent from my phone. Typos are a kind gift to anyone who happens to find them. On Fri, Dec 24, 2021, 17: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 > > >
