On Fri, Dec 24, 2021 at 5:21 PM Dominik Psenner <dpsen...@gmail.com> wrote:
> 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. > Nice write up Dominick & something I can get behind. Gary > > -- > 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 > > > > > > >
