Hey, TL;DR: I have no intention to contribute anything but a security fix, and I don't think there's anyone who thinks differently. I'll provide a patch but won't/can't make the official release.
>From my side what I volunteered for is to propose changes that should go in that fix for review. I guess I'm proposing more changes than you expected! Must be my internal quality bar: IMO an apache release should (primarily) be a source release that's easy to (re)build and test. That's been quite a bit of effort. By comparison, getting rid of some old java code is much easier :) Since I'm not a committer or PMC member, I can't really manage a release or publish the website. (I probably also won't have time for it next week.) Someone else would have to step up for that. Similarly to set up git(hub) requires a PMC member. Hopefully the [VOTE] on that is revisited and then someone sets it up. Otherwise we can figure out how to coerce a [PATCH] mail out of git to apply to svn. I hope we can get PR(s) into a good enough shape to convince the PMC to accept the changes and make a release. But if the PMC ultimately cannot or does not want to do that, no harm done, no work lost. In that case we can put an unofficial release somewhere on github. Personally I think for end users that will be less clear/convenient, but I also think reasonable people can have different perspectives there. Fortunately apache doesn't always require full consensus, just enough +1s and enough volunteers, so I have some hope :) Cheers, Leo On Fri, Dec 17, 2021 at 7:28 PM Ralph Goers <ralph.go...@dslextreme.com> wrote: > I am still questioning the plan. If you are planning on just creating a > security release > and then having the project go back to its coffin then I am not sure why > all the tooling > is needed. OTOH, if you want to resurrect the project then this really > should go through > the ASF incubator with the Logging Services project as the sponsor. > > Ralph > > > On Dec 17, 2021, at 10:24 AM, Leo Simons <m...@leosimons.com> wrote: > > > > Hey, > > > > Progress today > > ---- > > As mentioned I made a draft PR for the branch I'm working on: > > > > https://github.com/apache/log4j/pull/16 > > > > My main progress today was to get the unit test suite working reliably > > (dozens of tests were disabled because they had flaky results), and then > to > > get build and test to run reliably on a bunch of different > JDK/toolchain/OS > > combos, using github actions for CI: > > > > https://github.com/lsimons/log4j/actions/runs/1593087224 > > > > I also read through the SyslogAppender which I thought about > > disabling completely, but have opted for a stern warning instead for any > > configs that write to non-localhost. > > > > In the net package, SMTPAppender still needs more of an opinion on what > to > > do exactly (see some notes on the e-mail thread Tony started). > > > > Other PRs > > ---- > > I've also cherry-picked a couple of reasonable PRs into the branch I'm > > working on: > > > > https://github.com/apache/log4j/pull/13 (by Geertjan Wielenga) > > https://github.com/apache/log4j/pull/10 (by Vincent Privat) > > > > For the remaining ones I went through them and wrote suggestions for > what I > > think should happen, which amounts to: all PRs except for the new #16 > > should be closed. (I don't have permission to click "Close" of course.) > > > > Integration tests > > ---- > > Existing test suite took so much time that I didn't get around to > starting > > on any integration tests yet. > > > > I would like to have some fixture projects set up into which to > auto-inject > > different problematic config files and 1.x libraries, assert there is a > > problem, replace with the new library, assert it's ok. > > > > Wondering if it's easy to make it all a bit sysadmin friendly (i.e. shell > > scripts / docker / ...), so you don't need to know java to see the > problem > > or to verify the solution. > > > > ...and then it'd make sense to me to have another git repo. > > > > > > Cheers, > > > > > > Leo > >
