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
