I'm not against applying patches to the svn repo, either. I haven't forgotten how to use svn as I still use it for Secretary stuff (plus where we put release artifacts). Given that a PMC member would need to do part of the release anyways, that hopefully isn't a blocker.
I'm +1 for making a minimal 1.2.18 release to address CVEs. If there are any major bugs that have a simple fix, those might also qualify, but I wouldn't recommend spending much time there. Log4j 1.x has some intractable bugs that were only fixed in subsequent projects like Log4j 2.x and Logback. On Mon, Dec 20, 2021 at 12:39 PM Andrii Berezovskyi <[email protected]> wrote: > > Dear Vladimir, > > > When it comes to code-related changes, the reviews are vague, and it is > > really hard (impossible?) to find consensus. > I somehow got an idea that ripping out classes that could lead to a > NoClassDefFoundError for existing users did not fit the definition of "binary > compability" for the log4j2 committers. As much as I would love to rip the > classes in question out, I must admit that doing so is not binary compatible. > > And if I recall correctly, the request on > https://github.com/apache/log4j/pull/17 was to separate build changes from > the code fixes and start with a PR to fix one CVE only (and have that fix to > be something else than removing a class) so that can be reviewed in > reasonable time. And if I read between the lines well, the committers wanted > to see viable PRs before doing infra work that you are (correctly) > suggesting. But apologies for butting in if I got something wrong. > > Best regards, > Andrew
