It's possible that it's not buildable without updates to the build scripts. If that's the case, then they should be updated.
On Fri, Dec 17, 2021 at 12: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 >
