Re: [LOG4J 1] standardizing the Maven build

2022-01-06 Thread Leo Simons
Hey Ceki, Builds and tests were already fixed up, see the most recent outstanding PRs. Might be faster to cherry-pick rather than to re-do; if you start to move things around you’ll have a hard time merging anything in. Cheers, Leo On Thu, 6 Jan 2022 at 19:39, Ceki Gülcü wrote: > > Hello all,

Re: [DISCUSS][VOTE] Future of Log4j 1.x

2022-01-01 Thread Leo Simons
Hey, Happy new year everyone! On Wed, Dec 29, 2021 at 8:54 PM Ralph Goers wrote: > Leo seemed interested at first but didn’t weigh in on the discussion > thread. I'm here. I did mention in a couple mails I'd be away. Real life happens :). I think I made clear what I am interested in through

Re: [VOTE] Move apache/log4j1 Git repo to apache/logging-log4j1 Git repo

2021-12-24 Thread Leo Simons
I see good arguments either way. Most important to me is clarity and a mandated way forward. This would work well! If you /don’t/ rename it, ideally it’s PRs should be closed, a “look elsewhere” README added, and then set to “archived” in GitHub settings. As extra step could also rename it logging

Re: Log4J 1.x progress, pull request(s), plans

2021-12-23 Thread Leo Simons
On Thu, 23 Dec 2021 at 15:43, Christian Grobmeier wrote: > I didn't see the PRs though - are they still local on your box? On the wrong repo and lacking a target branch: https://github.com/apache/log4j/pull/17 https://github.com/apache/log4j/pull/16 From https://github.com/lsimons/log4j For

Re: Log4J 1.x progress, pull request(s), plans

2021-12-23 Thread Leo Simons
Thanks for chipping in Christian! Your detailed notes from back then helped a ton figure basic things out. What I did for the PRs I made is to * also check in the 32 bit 1.2.17 dll from the binary release, like was already done for 64 bit, * have the maven build not auto-attempt to build it, * ma

Re: New Log4j 1 repo

2021-12-23 Thread Leo Simons
Hey, I am interested in legacy/vintage core enterprise systems deep inside large enterprises and governments, where source code changes are out of the question, that have lit up yellow in security/compliance dashboards due to the old CVE against log4j 1.2 for years, that now light up as orange due

Re: New Log4j 1 repo

2021-12-23 Thread Leo Simons
think > maven 3 runs on Java 6. > > Ralph > > > On Dec 23, 2021, at 5:11 AM, Leo Simons wrote: > > > > On Thu, 23 Dec 2021 at 12:39, Ralph Goers > > wrote: > > > >> It is still the middle of the night for me so I won’t do anything for > >>

Re: New Log4j 1 repo

2021-12-23 Thread Leo Simons
On Thu, 23 Dec 2021 at 12:39, Ralph Goers wrote: > It is still the middle of the night for me so I won’t do anything for > several hours. Whoa, best get some rest! :) I will create the branch but I am curious about the rest. When I ran the > build last night it ran through a bunch of unit test

Re: New Log4j 1 repo

2021-12-23 Thread Leo Simons
(On mobile) Cool. First I suggest to make a new branch from 1.2.17. Trunk has various stuff that’s backwards incompatible. Something like git checkout -b main v1_0_2_17 git push -u main Then go into GitHub settings and make main the default branch. So then people make PRs against that. Think

Re: Resurrecting log4j 1.x

2021-12-21 Thread Leo Simons
On Tue, 21 Dec 2021 at 18:48, Gary Gregory wrote: > … > I wonder what logback actually means by "Temporarily removed DB support for > security reasons.", did they remove public or protected code? Well we have > enough to deal with here without worrying about that. Yeah they deleted DBAppender.

Re: Resurrecting log4j 1.x

2021-12-21 Thread Leo Simons
(On mobile, excuse typos/top post) +1. My interest is in staying here, work together, make a security release as one community (and I probably will be gone when security is no longer a topic), that is as good as possible, out soon(tm). I won’t object to but also won’t join something “new” (feel fr

Re: Log4J 1.x progress, pull request(s), plans

2021-12-19 Thread Leo Simons
Hey folks, So as requested I've made a conservative fully binary compatible version of all the build changes and security fixes, patches are on a new pull request at https://github.com/apache/log4j/pull/17 On Sat, Dec 18, 2021 at 7:30 PM Gary Gregory wrote: > Again, you cannot break binary

Re: Log4J 1.x progress, pull request(s), plans

2021-12-18 Thread Leo Simons
On Sat, Dec 18, 2021 at 5:32 PM Leo Simons wrote: > On Sat, Dec 18, 2021 at 3:34 PM Gary Gregory > wrote: > >> If you delete anything that is public or protected, you will break >> binary compatibility, and that's a no-go IMO. > > > Agree. I hope we can get c

Re: Log4J 1.x progress, pull request(s), plans

2021-12-18 Thread Leo Simons
Hey, On Sat, Dec 18, 2021 at 1:52 PM Vladimir Sitnikov < sitnikov.vladi...@gmail.com> wrote: > >Similarly to set up git(hub) requires a PMC member. > >Hopefully the [VOTE] on that is revisited and then someone sets it up. > > Would you please express your opinion on "[VOTE] Move log4j 1.x from SV

Re: [VOTE] Move log4j 1.x from SVN to Git, use the current apache/log4j mirror

2021-12-18 Thread Leo Simons
+1 from me. I imagine it should make it easier to make the security release when setup for 1.2 is more similar to 2.x. That should mean people who are good at releasing 2.x have an easy time releasing 1.2.18. I think we can (and should) do this in such a way that 1.2 EOL status becomes *more* cle

Re: Log4J 1.x progress, pull request(s), plans

2021-12-18 Thread Leo Simons
Hey Gary, On Sat, Dec 18, 2021 at 3:34 PM Gary Gregory wrote: > If you delete anything that is public or protected, you will break > binary compatibility, and that's a no-go IMO. Agree. I hope we can get clirr (or something like it) back to work, to prove binary compatibility. Perhaps with on

Re: Log4J 1.x progress, pull request(s), plans

2021-12-18 Thread Leo Simons
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 wr

Re: JIRA for tracking 1.x release? also some input.

2021-12-17 Thread Leo Simons
On Fri, Dec 17, 2021 at 6:24 PM Vladimir Sitnikov < sitnikov.vladi...@gmail.com> wrote: > >Note removing the classes would break API compatibility > > I do not think keeping the class with "every method throws" is much better > than just removing the class. > Agreed! I also don't want to do "ever

Log4J 1.x progress, pull request(s), plans

2021-12-17 Thread Leo Simons
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

Re: JIRA for tracking 1.x release? also some input.

2021-12-17 Thread Leo Simons
Hi Tony, Glad you want to help. The original Log4J community left, so to get anything done we need some new contributors! On Thu, Dec 16, 2021 at 9:19 PM Homer, Tony wrote: > There has been some discussion about releasing a security update for log4j > 1.x (1.2.18, perhaps), both here and on > h

Re: Log4j 1.x compatibility

2021-12-16 Thread Leo Simons
Hey Gary, Thanks for your thoughts. TL;DR: I actually share your preference! But: how? Also, progress notes. In a "normal" situation I really think that the 99% drop in replacement that is already there is plenty. Especially from an ASF perspective where our primary deliverable is source code to

Re: Cleaning up & releasing log4j 1.x

2021-12-15 Thread Leo Simons
become part of the logging project and support Log4j 1 we do > not want to give the impression that > > > it is being supported. > > > > > > Ralph > > > > > > > > > > > > > On Dec 15, 2021, at 10:14 AM, Leo Simons > wrote: > &g

Cleaning up & releasing log4j 1.x

2021-12-15 Thread Leo Simons
Hey folks, First, thanks for all the hard work on 2.x, especially these last couple of weeks! Please take care of yourself and be kind to yourself :) Obviously 2.x should get full focus from all that can productively contribute to it. I do agree with Vladimir about giving 1.x a little attention.