[RESULT][VOTE] Future of Log4j 1.x
Hello, this is the result of the below vote: 11x +1 (Option 1), all binding 1 x +0 (abstaing), non binding 1x -1 (objection against those options), non binding. Details: +1, Option 1 Dominik Psenner (binding) Robert Middleton (binding) Gary Gregory (binding) Ralph Goers (binding) Matt Sicker (binding) Christian Grobmeier (binding) Carter Kozak (binding) Ron Grabowski (binding) Volkan Yazıcı (binding) Remko Popma (binding) Davyd McColl (binding) +0: Xeno Amess (non binding) -1: Vladimir Sitnikov (non binding) The PMC decided unanimous to keep Log4 1 EOL. Since there was a lengthy discussion before and while this, the PMC Chair Ron Grabowski will send a statement which explains the thoughts behind this decision in detail. Kind regards, Christian Hello, as discussed in another thread, this is a vote about the future of log4j 1. This vote stays open for the usual 72h. Options are explained below. You can vote for: [ ] +1, Option 1 [ ] +1, Option 2 [ ] +/- 0, abstain [ ] -1 object against those options Option 1: Create a README.md that publishes the projects EOL status and do nothing else. Option 2: Create a README which says the project is EOL but allow the following work for 1.2.18 AND create a full release: a. Make the build work with a modern version of Maven. b. Fix the Java version bug. c. Fix CVE-2021-4104 (expanded to address all JNDI components) d. Fix CVE-2019-17571 Regards, Christian -- The Apache Software Foundation V.P., Data Privacy
Re: [VOTE] Future of Log4j 1.x
+1, option 1 Apologies for the delay, took me a while to find the original email. -d On December 29, 2021 21:33:35 "Christian Grobmeier" wrote: Hello, as discussed in another thread, this is a vote about the future of log4j 1. This vote stays open for the usual 72h. Options are explained below. You can vote for: [ ] +1, Option 1 [ ] +1, Option 2 [ ] +/- 0, abstain [ ] -1 object against those options Option 1: Create a README.md that publishes the projects EOL status and do nothing else. Option 2: Create a README which says the project is EOL but allow the following work for 1.2.18 AND create a full release: a. Make the build work with a modern version of Maven. b. Fix the Java version bug. c. Fix CVE-2021-4104 (expanded to address all JNDI components) d. Fix CVE-2019-17571 Regards, Christian -- The Apache Software Foundation V.P., Data Privacy
Re: [VOTE] Future of Log4j 1.x
+1, option 1 -- Sent from my phone. Typos are a kind gift to anyone who happens to find them. On Tue, Jan 4, 2022, 22:19 Remko Popma wrote: > +1 for Option 1 > > On Wed, Jan 5, 2022 at 4:51 AM Volkan Yazıcı wrote: > > > +1, Option 1 > > > > On Wed, 29 Dec 2021, 20:33 Christian Grobmeier > > wrote: > > > > > Hello, > > > > > > as discussed in another thread, this is a vote about the future of > log4j > > > 1. This vote stays open for the usual 72h. > > > Options are explained below. > > > > > > You can vote for: > > > > > > [ ] +1, Option 1 > > > [ ] +1, Option 2 > > > [ ] +/- 0, abstain > > > [ ] -1 object against those options > > > > > > Option 1: Create a README.md that publishes the projects EOL status and > > do > > > nothing else. > > > Option 2: Create a README which says the project is EOL but allow the > > > following work for 1.2.18 AND create a full release: > > > a. Make the build work with a modern version of Maven. > > > b. Fix the Java version bug. > > > c. Fix CVE-2021-4104 (expanded to address all JNDI components) > > > d. Fix CVE-2019-17571 > > > > > > Regards, > > > Christian > > > -- > > > The Apache Software Foundation > > > V.P., Data Privacy > > > > > >
Re: [VOTE] Future of Log4j 1.x
+1 for Option 1 On Wed, Jan 5, 2022 at 4:51 AM Volkan Yazıcı wrote: > +1, Option 1 > > On Wed, 29 Dec 2021, 20:33 Christian Grobmeier > wrote: > > > Hello, > > > > as discussed in another thread, this is a vote about the future of log4j > > 1. This vote stays open for the usual 72h. > > Options are explained below. > > > > You can vote for: > > > > [ ] +1, Option 1 > > [ ] +1, Option 2 > > [ ] +/- 0, abstain > > [ ] -1 object against those options > > > > Option 1: Create a README.md that publishes the projects EOL status and > do > > nothing else. > > Option 2: Create a README which says the project is EOL but allow the > > following work for 1.2.18 AND create a full release: > > a. Make the build work with a modern version of Maven. > > b. Fix the Java version bug. > > c. Fix CVE-2021-4104 (expanded to address all JNDI components) > > d. Fix CVE-2019-17571 > > > > Regards, > > Christian > > -- > > The Apache Software Foundation > > V.P., Data Privacy > > >
Re: [VOTE] Future of Log4j 1.x
+1, Option 1 On Wed, 29 Dec 2021, 20:33 Christian Grobmeier wrote: > Hello, > > as discussed in another thread, this is a vote about the future of log4j > 1. This vote stays open for the usual 72h. > Options are explained below. > > You can vote for: > > [ ] +1, Option 1 > [ ] +1, Option 2 > [ ] +/- 0, abstain > [ ] -1 object against those options > > Option 1: Create a README.md that publishes the projects EOL status and do > nothing else. > Option 2: Create a README which says the project is EOL but allow the > following work for 1.2.18 AND create a full release: > a. Make the build work with a modern version of Maven. > b. Fix the Java version bug. > c. Fix CVE-2021-4104 (expanded to address all JNDI components) > d. Fix CVE-2019-17571 > > Regards, > Christian > -- > The Apache Software Foundation > V.P., Data Privacy >
Re: [VOTE] Future of Log4j 1.x
+1 for Option 1 On 12/29/2021 2:33 PM, Christian Grobmeier wrote: Hello, as discussed in another thread, this is a vote about the future of log4j 1. This vote stays open for the usual 72h. Options are explained below. You can vote for: [ ] +1, Option 1 [ ] +1, Option 2 [ ] +/- 0, abstain [ ] -1 object against those options Option 1: Create a README.md that publishes the projects EOL status and do nothing else. Option 2: Create a README which says the project is EOL but allow the following work for 1.2.18 AND create a full release: a. Make the build work with a modern version of Maven. b. Fix the Java version bug. c. Fix CVE-2021-4104 (expanded to address all JNDI components) d. Fix CVE-2019-17571 Regards, Christian -- The Apache Software Foundation V.P., Data Privacy
Re: [VOTE] Future of Log4j 1.x
+1 Option 1 -ck > On Dec 29, 2021, at 14:33, Christian Grobmeier wrote: > > Hello, > > as discussed in another thread, this is a vote about the future of log4j 1. > This vote stays open for the usual 72h. > Options are explained below. > > You can vote for: > > [ ] +1, Option 1 > [ ] +1, Option 2 > [ ] +/- 0, abstain > [ ] -1 object against those options > > Option 1: Create a README.md that publishes the projects EOL status and do > nothing else. > Option 2: Create a README which says the project is EOL but allow the > following work for 1.2.18 AND create a full release: >a. Make the build work with a modern version of Maven. >b. Fix the Java version bug. >c. Fix CVE-2021-4104 (expanded to address all JNDI components) >d. Fix CVE-2019-17571 > > Regards, > Christian > -- > The Apache Software Foundation > V.P., Data Privacy
Re: [VOTE] Future of Log4j 1.x
+1, Option 1 On Wed, Dec 29, 2021, at 20:33, Christian Grobmeier wrote: > Hello, > > as discussed in another thread, this is a vote about the future of > log4j 1. This vote stays open for the usual 72h. > Options are explained below. > > You can vote for: > > [ ] +1, Option 1 > [ ] +1, Option 2 > [ ] +/- 0, abstain > [ ] -1 object against those options > > Option 1: Create a README.md that publishes the projects EOL status and > do nothing else. > Option 2: Create a README which says the project is EOL but allow the > following work for 1.2.18 AND create a full release: > a. Make the build work with a modern version of Maven. > b. Fix the Java version bug. > c. Fix CVE-2021-4104 (expanded to address all JNDI components) > d. Fix CVE-2019-17571 > > Regards, > Christian > -- > The Apache Software Foundation > V.P., Data Privacy
Re: [DISCUSS][VOTE] Future of Log4j 1.x
Hi Leo, good new year to you! On Sun, Jan 2, 2022, at 07:12, Leo Simons wrote: > 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 several emails and in > code. > I've also pointed out what I wouldn't do (like step up as a maintainer on a > permanent basis, or incubate something). I think you are very welcome at this place and no matter the outcome of this vote, let us discuss how you can still find an open source home here. I know you have a different opinion, but learning more about Log4j1 I think a person with your skills and dedication is more than welcome in working with log4j 1 migration. cheers! > I think all the relevant arguments on how to proceed with 1.x have been > made (a few times...). > I don't have anything new to add. > I'll accept the vote outcome. > > > Cheers! > > > Leo
Re: [DISCUSS][VOTE] Future of Log4j 1.x
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 several emails and in code. I've also pointed out what I wouldn't do (like step up as a maintainer on a permanent basis, or incubate something). I think all the relevant arguments on how to proceed with 1.x have been made (a few times...). I don't have anything new to add. I'll accept the vote outcome. Cheers! Leo
Re: [VOTE] Future of Log4j 1.x
I’m +1 for option one. For projects that ignored published CVEs for multiple years and then ignored the EOL announcement, I don’t see any reason they’d bother updating their ancient copies. Given the release difficulty in making something that’s compatible with previous releases makes this even more of a waste of time. — Matt Sicker > On Jan 1, 2022, at 11:20, Jochen Wiedmann wrote: > > On Sat, Jan 1, 2022 at 4:40 PM Xeno Amess wrote: > >>> People should migrate to log4j2. >> good thinking, but what if they migrate to logback... > > No, it's not (good thinking, that is). > > Log4j1 is a part of basically *every* Java based server software, that > I am aware of. People don't want to touch those. They need a drop-in > replacement, not a successor. Over the last week, I was *really > puzzled* about all the stuff that claims to be affected by the > problems in log4j2. And that's the lesser used of the two... > > Jochen > > > > Philosophy is useless, theology is worse. (Industrial Desease, Dire Straits)
Re: [VOTE] Future of Log4j 1.x
On Sat, Jan 1, 2022, at 18:19, Jochen Wiedmann wrote: > On Sat, Jan 1, 2022 at 4:40 PM Xeno Amess wrote: > >> > People should migrate to log4j2. >> good thinking, but what if they migrate to logback... > > No, it's not (good thinking, that is). > > Log4j1 is a part of basically *every* Java based server software, that > I am aware of. People don't want to touch those. They need a drop-in > replacement, not a successor. Over the last week, I was *really > puzzled* about all the stuff that claims to be affected by the > problems in log4j2. And that's the lesser used of the two... For what exactly do we need that now? The security issues in log4j1 are 10 years old and you just don't have to use JMSAppender and you are good too go. Cheers, Christian > Jochen > > > > Philosophy is useless, theology is worse. (Industrial Desease, Dire Straits)
Re: [VOTE] Future of Log4j 1.x
On Sat, Jan 1, 2022 at 4:40 PM Xeno Amess wrote: > > People should migrate to log4j2. > good thinking, but what if they migrate to logback... No, it's not (good thinking, that is). Log4j1 is a part of basically *every* Java based server software, that I am aware of. People don't want to touch those. They need a drop-in replacement, not a successor. Over the last week, I was *really puzzled* about all the stuff that claims to be affected by the problems in log4j2. And that's the lesser used of the two... Jochen Philosophy is useless, theology is worse. (Industrial Desease, Dire Straits)
[DISCUSS][VOTE] Future of Log4j 1.x
Discussion shouldn’t happen on the main vote thread please. Users are certainly free to use Logback. If they are OK with losing log events during reconfiguration and using a framework that is maintained by one person and are OK when he disappears for a year and a half that is their choice. Please remember, this is not a commercial venture. No Java logging framework is. Switching to Logback also requires work. It doesn’t natively support Log4j 1 configuration files. Log4j 2 does support Log4j 1 configuration using the Log4j 1.2 bridge, which we are constantly improving. But the bottom line is that I would prefer that users migrate to Logback over sticking with Log4j 1. Although it has many of Log4j 1’s flaws it does not suffer from the multi-threading issues that Log4j 1 has. Of course, I think Log4j 2 is a better choice, but I am obviously biased. Happy New Year! Ralph > On Jan 1, 2022, at 8:40 AM, Xeno Amess wrote: > > +0 > >> People should migrate to log4j2. > good thinking, but what if they migrate to logback... > IMO logback is a thing more likely log4j1 than log4j2, just user side. > > > Ralph Goers 于2022年1月1日周六 23:18写道： > >> +1 to Option 1 >> >> Ralph >> >>> On Dec 29, 2021, at 12:33 PM, Christian Grobmeier >> wrote: >>> >>> Hello, >>> >>> as discussed in another thread, this is a vote about the future of log4j >> 1. This vote stays open for the usual 72h. >>> Options are explained below. >>> >>> You can vote for: >>> >>> [ ] +1, Option 1 >>> [ ] +1, Option 2 >>> [ ] +/- 0, abstain >>> [ ] -1 object against those options >>> >>> Option 1: Create a README.md that publishes the projects EOL status and >> do nothing else. >>> Option 2: Create a README which says the project is EOL but allow the >> following work for 1.2.18 AND create a full release: >>> a. Make the build work with a modern version of Maven. >>> b. Fix the Java version bug. >>> c. Fix CVE-2021-4104 (expanded to address all JNDI components) >>> d. Fix CVE-2019-17571 >>> >>> Regards, >>> Christian >>> -- >>> The Apache Software Foundation >>> V.P., Data Privacy >>> >> >>
Re: [VOTE] Future of Log4j 1.x
+0 > People should migrate to log4j2. good thinking, but what if they migrate to logback... IMO logback is a thing more likely log4j1 than log4j2, just user side. Ralph Goers 于2022年1月1日周六 23:18写道： > +1 to Option 1 > > Ralph > > > On Dec 29, 2021, at 12:33 PM, Christian Grobmeier > wrote: > > > > Hello, > > > > as discussed in another thread, this is a vote about the future of log4j > 1. This vote stays open for the usual 72h. > > Options are explained below. > > > > You can vote for: > > > > [ ] +1, Option 1 > > [ ] +1, Option 2 > > [ ] +/- 0, abstain > > [ ] -1 object against those options > > > > Option 1: Create a README.md that publishes the projects EOL status and > do nothing else. > > Option 2: Create a README which says the project is EOL but allow the > following work for 1.2.18 AND create a full release: > >a. Make the build work with a modern version of Maven. > >b. Fix the Java version bug. > >c. Fix CVE-2021-4104 (expanded to address all JNDI components) > >d. Fix CVE-2019-17571 > > > > Regards, > > Christian > > -- > > The Apache Software Foundation > > V.P., Data Privacy > > > >
Re: [DISCUSS][VOTE] Future of Log4j 1.x
These show up as two distinct threads In Mail on my MacBook Pro. FWIW, the PMC is aware of at least two distributions that already seem to fulfill the need of providing patched versions of Log4 1: 1. https://github.com/albfernandez/log4j/ 2. https://search.maven.org/artifact/io.confluent/confluent-log4j (The source appears to be in a private repository). Of course, both of these use different maven coordinates than Apache Log4j so users will have to ensure they exclude the Apache Log4j dependencies. Ralph > On Dec 30, 2021, at 5:23 AM, Vladimir Sitnikov > wrote: > > Christian>vote in this thread, which is, btw not meant for discussion but > for voting. > > We are on a [DISCUSS] thread (check the subject). > > Ralph "created" [DISCUSS] thread by hitting "reply" and changing the > subject. > "reply" keeps message-id, so it might look like a single thread. > > See both "[DISCUSS][VOTE] Future of Log4j 1.x" and "[VOTE] Future of Log4j > 1.x" > at https://lists.apache.org/list.html?dev@logging.apache.org > > Vladimir
Re: [VOTE] Future of Log4j 1.x
+1 to Option 1 Ralph > On Dec 29, 2021, at 12:33 PM, Christian Grobmeier > wrote: > > Hello, > > as discussed in another thread, this is a vote about the future of log4j 1. > This vote stays open for the usual 72h. > Options are explained below. > > You can vote for: > > [ ] +1, Option 1 > [ ] +1, Option 2 > [ ] +/- 0, abstain > [ ] -1 object against those options > > Option 1: Create a README.md that publishes the projects EOL status and do > nothing else. > Option 2: Create a README which says the project is EOL but allow the > following work for 1.2.18 AND create a full release: >a. Make the build work with a modern version of Maven. >b. Fix the Java version bug. >c. Fix CVE-2021-4104 (expanded to address all JNDI components) >d. Fix CVE-2019-17571 > > Regards, > Christian > -- > The Apache Software Foundation > V.P., Data Privacy >
Re: [VOTE] Future of Log4j 1.x
[X] +1, Option 1 Gary On Wed, Dec 29, 2021 at 2:33 PM Christian Grobmeier wrote: > Hello, > > as discussed in another thread, this is a vote about the future of log4j > 1. This vote stays open for the usual 72h. > Options are explained below. > > You can vote for: > > [ ] +1, Option 1 > [ ] +1, Option 2 > [ ] +/- 0, abstain > [ ] -1 object against those options > > Option 1: Create a README.md that publishes the projects EOL status and do > nothing else. > Option 2: Create a README which says the project is EOL but allow the > following work for 1.2.18 AND create a full release: > a. Make the build work with a modern version of Maven. > b. Fix the Java version bug. > c. Fix CVE-2021-4104 (expanded to address all JNDI components) > d. Fix CVE-2019-17571 > > Regards, > Christian > -- > The Apache Software Foundation > V.P., Data Privacy >
Re: [VOTE] Future of Log4j 1.x
+1 to option 1 -Robert Middleton On Wed, Dec 29, 2021 at 2:33 PM Christian Grobmeier wrote: > > Hello, > > as discussed in another thread, this is a vote about the future of log4j 1. > This vote stays open for the usual 72h. > Options are explained below. > > You can vote for: > > [ ] +1, Option 1 > [ ] +1, Option 2 > [ ] +/- 0, abstain > [ ] -1 object against those options > > Option 1: Create a README.md that publishes the projects EOL status and do > nothing else. > Option 2: Create a README which says the project is EOL but allow the > following work for 1.2.18 AND create a full release: > a. Make the build work with a modern version of Maven. > b. Fix the Java version bug. > c. Fix CVE-2021-4104 (expanded to address all JNDI components) > d. Fix CVE-2019-17571 > > Regards, > Christian > -- > The Apache Software Foundation > V.P., Data Privacy
Re: [DISCUSS][VOTE] Future of Log4j 1.x
Christian>vote in this thread, which is, btw not meant for discussion but for voting. We are on a [DISCUSS] thread (check the subject). Ralph "created" [DISCUSS] thread by hitting "reply" and changing the subject. "reply" keeps message-id, so it might look like a single thread. See both "[DISCUSS][VOTE] Future of Log4j 1.x" and "[VOTE] Future of Log4j 1.x" at https://lists.apache.org/list.html?dev@logging.apache.org Vladimir
Re: [DISCUSS][VOTE] Future of Log4j 1.x
If there is long term commitment apart from these urgent fixes we can run another vote. You cannot guarantee you are alive by February, nobody can give such guarantees. The logging pmc is not here to accept all patches as they come in but to make decisions best to the project (among other duties). Once there is a mandate and consent among pmc we most likely try to review and comment on the prs coming in. No guarantees though your pr will be accepted as it is. That said, we continue to vote in New committers and pmc members as we always have. Prerequisites to become logging committer is long term interest in logging and understanding the ASF way. Also, I daresay, many people here like to add new people when they are adding positive attitude (versus toxic behavior). I hope all your questions are clarified now and we can continue to discuss (see Ralph's message) on slack and vote in this thread, which is, btw not meant for discussion but for voting. -- The Apache Software Foundation V.P., Data Privacy On Wed, Dec 29, 2021, at 21:41, Vladimir Sitnikov wrote: >>Log4j is owned by the Logging Services PMC. You cannot incubate it without > this PMC’s approval. > > Exactly. As far as I understand, Logging pmc should accept patches and > release fixes or they should approve reincubating. > Of course, you can try rejecting patches and disapprove reincubation, > however, that won't hold water. > > Unfortunately, I have not seen the response from the logging pmc regarding > approve/disapprove re-incubating. There's a pending question to Ron still. > > I do not consider forks outside of the ASF. > >>But I notice the one topic you did not respond to was the lack of > interested people other than yourself. Why is that? > > I find the question irrelevant, and I find it has nothing to do with > accepting patches and releasing 1.2 > I belive there were even people on incubator thread, so it is strange why > do you demand that I provide you with a list of rock-star 1.x maintainers. > > 1) I can't guarantee I will be alive in February. Can you guarantee all the > logging pmc members will be alive then? I doubt so. So I find that > questions like "how can we be sure you will send patches" too intimate. > > 2) I have already filed a patch for buildscripts. Whould you review it and > merge? > > 3) Suppose I find a team (e.g 4-5 ASF fellows) who are willing to support > 1.2. What do you do then? Would you add all of them to the logging pmc? > I don't really see the point why do you ask, and at the same time I can't > guarantee the people I gather will be alive tomorrow. I can't guarantee > they will always have interest in 1.2 > > Vladimir
Re: [DISCUSS][VOTE] Future of Log4j 1.x
Makes sense. I will close thus vote not earlier than Jan 5, if there is no further objections. Thanks for your input Tim -- The Apache Software Foundation V.P., Data Privacy On Thu, Dec 30, 2021, at 01:56, Tim Perry wrote: > I propose that this vote should stay open longer than 72 hours given > that we are coming up on New Years and many people who would wish to > weigh in might be on vacation right now. > > Tim > >> On Dec 29, 2021, at 2:29 PM, Matt Sicker wrote: >> >> Consistent contributors are frequently invited to be committers and later >> PMC members. Having at least three people maintaining anything is an Apache >> standard for maintaining vendor neutrality, ensuring a minimum number of >> people can verify release candidates to address security issues or any other >> releases. >> >> — >> Matt Sicker >> >>> On Dec 29, 2021, at 14:41, Vladimir Sitnikov >>> wrote: >>> >>> Log4j is owned by the Logging Services PMC. You cannot incubate it without >>> this PMC’s approval. >>> >>> Exactly. As far as I understand, Logging pmc should accept patches and >>> release fixes or they should approve reincubating. >>> Of course, you can try rejecting patches and disapprove reincubation, >>> however, that won't hold water. >>> >>> Unfortunately, I have not seen the response from the logging pmc regarding >>> approve/disapprove re-incubating. There's a pending question to Ron still. >>> >>> I do not consider forks outside of the ASF. >>> But I notice the one topic you did not respond to was the lack of >>> interested people other than yourself. Why is that? >>> >>> I find the question irrelevant, and I find it has nothing to do with >>> accepting patches and releasing 1.2 >>> I belive there were even people on incubator thread, so it is strange why >>> do you demand that I provide you with a list of rock-star 1.x maintainers. >>> >>> 1) I can't guarantee I will be alive in February. Can you guarantee all the >>> logging pmc members will be alive then? I doubt so. So I find that >>> questions like "how can we be sure you will send patches" too intimate. >>> >>> 2) I have already filed a patch for buildscripts. Whould you review it and >>> merge? >>> >>> 3) Suppose I find a team (e.g 4-5 ASF fellows) who are willing to support >>> 1.2. What do you do then? Would you add all of them to the logging pmc? >>> I don't really see the point why do you ask, and at the same time I can't >>> guarantee the people I gather will be alive tomorrow. I can't guarantee >>> they will always have interest in 1.2 >>> >>> Vladimir
Re: [DISCUSS][VOTE] Future of Log4j 1.x
+1, Option 1 People should migrate to log4j2. On Thu, 30 Dec 2021 at 01:56, Tim Perry wrote: > I propose that this vote should stay open longer than 72 hours given that > we are coming up on New Years and many people who would wish to weigh in > might be on vacation right now. > > Tim > > > On Dec 29, 2021, at 2:29 PM, Matt Sicker wrote: > > > > Consistent contributors are frequently invited to be committers and > later PMC members. Having at least three people maintaining anything is an > Apache standard for maintaining vendor neutrality, ensuring a minimum > number of people can verify release candidates to address security issues > or any other releases. > > > > — > > Matt Sicker > > > >> On Dec 29, 2021, at 14:41, Vladimir Sitnikov < > sitnikov.vladi...@gmail.com> wrote: > >> > >> > >>> > >>> Log4j is owned by the Logging Services PMC. You cannot incubate it > without > >> this PMC’s approval. > >> > >> Exactly. As far as I understand, Logging pmc should accept patches and > >> release fixes or they should approve reincubating. > >> Of course, you can try rejecting patches and disapprove reincubation, > >> however, that won't hold water. > >> > >> Unfortunately, I have not seen the response from the logging pmc > regarding > >> approve/disapprove re-incubating. There's a pending question to Ron > still. > >> > >> I do not consider forks outside of the ASF. > >> > >>> But I notice the one topic you did not respond to was the lack of > >> interested people other than yourself. Why is that? > >> > >> I find the question irrelevant, and I find it has nothing to do with > >> accepting patches and releasing 1.2 > >> I belive there were even people on incubator thread, so it is strange > why > >> do you demand that I provide you with a list of rock-star 1.x > maintainers. > >> > >> 1) I can't guarantee I will be alive in February. Can you guarantee all > the > >> logging pmc members will be alive then? I doubt so. So I find that > >> questions like "how can we be sure you will send patches" too intimate. > >> > >> 2) I have already filed a patch for buildscripts. Whould you review it > and > >> merge? > >> > >> 3) Suppose I find a team (e.g 4-5 ASF fellows) who are willing to > support > >> 1.2. What do you do then? Would you add all of them to the logging pmc? > >> I don't really see the point why do you ask, and at the same time I > can't > >> guarantee the people I gather will be alive tomorrow. I can't guarantee > >> they will always have interest in 1.2 > >> > >> Vladimir > -- Dominik Psenner
Re: [DISCUSS][VOTE] Future of Log4j 1.x
I propose that this vote should stay open longer than 72 hours given that we are coming up on New Years and many people who would wish to weigh in might be on vacation right now. Tim > On Dec 29, 2021, at 2:29 PM, Matt Sicker wrote: > > Consistent contributors are frequently invited to be committers and later > PMC members. Having at least three people maintaining anything is an Apache > standard for maintaining vendor neutrality, ensuring a minimum number of > people can verify release candidates to address security issues or any other > releases. > > — > Matt Sicker > >> On Dec 29, 2021, at 14:41, Vladimir Sitnikov >> wrote: >> >> >>> >>> Log4j is owned by the Logging Services PMC. You cannot incubate it without >> this PMC’s approval. >> >> Exactly. As far as I understand, Logging pmc should accept patches and >> release fixes or they should approve reincubating. >> Of course, you can try rejecting patches and disapprove reincubation, >> however, that won't hold water. >> >> Unfortunately, I have not seen the response from the logging pmc regarding >> approve/disapprove re-incubating. There's a pending question to Ron still. >> >> I do not consider forks outside of the ASF. >> >>> But I notice the one topic you did not respond to was the lack of >> interested people other than yourself. Why is that? >> >> I find the question irrelevant, and I find it has nothing to do with >> accepting patches and releasing 1.2 >> I belive there were even people on incubator thread, so it is strange why >> do you demand that I provide you with a list of rock-star 1.x maintainers. >> >> 1) I can't guarantee I will be alive in February. Can you guarantee all the >> logging pmc members will be alive then? I doubt so. So I find that >> questions like "how can we be sure you will send patches" too intimate. >> >> 2) I have already filed a patch for buildscripts. Whould you review it and >> merge? >> >> 3) Suppose I find a team (e.g 4-5 ASF fellows) who are willing to support >> 1.2. What do you do then? Would you add all of them to the logging pmc? >> I don't really see the point why do you ask, and at the same time I can't >> guarantee the people I gather will be alive tomorrow. I can't guarantee >> they will always have interest in 1.2 >> >> Vladimir
Re: [DISCUSS][VOTE] Future of Log4j 1.x
Consistent contributors are frequently invited to be committers and later PMC members. Having at least three people maintaining anything is an Apache standard for maintaining vendor neutrality, ensuring a minimum number of people can verify release candidates to address security issues or any other releases. — Matt Sicker > On Dec 29, 2021, at 14:41, Vladimir Sitnikov > wrote: > > >> >> Log4j is owned by the Logging Services PMC. You cannot incubate it without > this PMC’s approval. > > Exactly. As far as I understand, Logging pmc should accept patches and > release fixes or they should approve reincubating. > Of course, you can try rejecting patches and disapprove reincubation, > however, that won't hold water. > > Unfortunately, I have not seen the response from the logging pmc regarding > approve/disapprove re-incubating. There's a pending question to Ron still. > > I do not consider forks outside of the ASF. > >> But I notice the one topic you did not respond to was the lack of > interested people other than yourself. Why is that? > > I find the question irrelevant, and I find it has nothing to do with > accepting patches and releasing 1.2 > I belive there were even people on incubator thread, so it is strange why > do you demand that I provide you with a list of rock-star 1.x maintainers. > > 1) I can't guarantee I will be alive in February. Can you guarantee all the > logging pmc members will be alive then? I doubt so. So I find that > questions like "how can we be sure you will send patches" too intimate. > > 2) I have already filed a patch for buildscripts. Whould you review it and > merge? > > 3) Suppose I find a team (e.g 4-5 ASF fellows) who are willing to support > 1.2. What do you do then? Would you add all of them to the logging pmc? > I don't really see the point why do you ask, and at the same time I can't > guarantee the people I gather will be alive tomorrow. I can't guarantee > they will always have interest in 1.2 > > Vladimir
Re: [DISCUSS][VOTE] Future of Log4j 1.x
>Log4j is owned by the Logging Services PMC. You cannot incubate it without this PMC’s approval. Exactly. As far as I understand, Logging pmc should accept patches and release fixes or they should approve reincubating. Of course, you can try rejecting patches and disapprove reincubation, however, that won't hold water. Unfortunately, I have not seen the response from the logging pmc regarding approve/disapprove re-incubating. There's a pending question to Ron still. I do not consider forks outside of the ASF. >But I notice the one topic you did not respond to was the lack of interested people other than yourself. Why is that? I find the question irrelevant, and I find it has nothing to do with accepting patches and releasing 1.2 I belive there were even people on incubator thread, so it is strange why do you demand that I provide you with a list of rock-star 1.x maintainers. 1) I can't guarantee I will be alive in February. Can you guarantee all the logging pmc members will be alive then? I doubt so. So I find that questions like "how can we be sure you will send patches" too intimate. 2) I have already filed a patch for buildscripts. Whould you review it and merge? 3) Suppose I find a team (e.g 4-5 ASF fellows) who are willing to support 1.2. What do you do then? Would you add all of them to the logging pmc? I don't really see the point why do you ask, and at the same time I can't guarantee the people I gather will be alive tomorrow. I can't guarantee they will always have interest in 1.2 Vladimir
Re: [DISCUSS][VOTE] Future of Log4j 1.x
You are a member of 2 ASF projects yet you don’t understand how the ASF works? Log4j is owned by the Logging Services PMC. You cannot incubate it without this PMC’s approval. You can certainly fork it outside the ASF but you cannot call it Log4j as the ASF owns the trademark. Sonatype would be unlikely to accept such a project with different maven coordinates that overlaps the log4j package naming as it would create a dependency mess. But I notice the one topic you did not respond to was the lack of interested people other than yourself. Why is that? Ralph > On Dec 29, 2021, at 1:05 PM, Vladimir Sitnikov > wrote: > > If you are not interested in maintaining 1.x, please give it away (to > another pmc or add pmc members) and that is it. > > Even if you all vote for option 1, then I would just reincubate 1.x or find > an alternative route to make 1.2.18, 1.2.19 and so on. So what is the point > of this vote then? You can't really prevent 1.2.18, 1.2.19, ... > > Vladimir
Re: [DISCUSS][VOTE] Future of Log4j 1.x
If you are not interested in maintaining 1.x, please give it away (to another pmc or add pmc members) and that is it. Even if you all vote for option 1, then I would just reincubate 1.x or find an alternative route to make 1.2.18, 1.2.19 and so on. So what is the point of this vote then? You can't really prevent 1.2.18, 1.2.19, ... Vladimir
[DISCUSS][VOTE] Future of Log4j 1.x
What “People”. So far you are the only person who seems interested. Leo seemed interested at first but didn’t weigh in on the discussion thread. AFAIK that’s it. Two people does not make a community. Furthermore, Log4j 1 was declared EOL 6 years ago and has been unsupported for 9 years. It will remain EOL until the PMC says otherwise. Ralph > On Dec 29, 2021, at 12:46 PM, Vladimir Sitnikov > wrote: > > -1 as it is invalid to say the project is "end of life" provided there are > people willing to support it. > > Vladimir
Re: [VOTE] Future of Log4j 1.x
-1 as it is invalid to say the project is "end of life" provided there are people willing to support it. Vladimir
[VOTE] Future of Log4j 1.x
Hello, as discussed in another thread, this is a vote about the future of log4j 1. This vote stays open for the usual 72h. Options are explained below. You can vote for: [ ] +1, Option 1 [ ] +1, Option 2 [ ] +/- 0, abstain [ ] -1 object against those options Option 1: Create a README.md that publishes the projects EOL status and do nothing else. Option 2: Create a README which says the project is EOL but allow the following work for 1.2.18 AND create a full release: a. Make the build work with a modern version of Maven. b. Fix the Java version bug. c. Fix CVE-2021-4104 (expanded to address all JNDI components) d. Fix CVE-2019-17571 Regards, Christian -- The Apache Software Foundation V.P., Data Privacy
