Agreed with all points of Carter.

It is either 1 or 4.
Anything more than 4 (including 5) is a hard no from me.

On Fri, Dec 24, 2021 at 6:00 PM Carter Kozak <cko...@ckozak.net> wrote:

> I would agree directionally with option 1 or option 4.
>
> Making changes without pushing binary artifacts to maven central (options
> 2 and 3) is unlikely to do much good for the types of projects which still
> use log4j1. Option 5 is a hard no from me, my time is already too
> constrained, there are better options, and the architecture limits
> substantive improvements.
>
> -ck
>
> On Fri, Dec 24, 2021, at 11:47, Ralph Goers 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
> >
> >
> >
>

Reply via email to