I am going to set up a vote for option 1 and 4. I think we have this thread
open for a long time already and don't expect many other responses
--
The Apache Software Foundation
V.P., Data Privacy
On Wed, Dec 29, 2021, at 07:55, Volkan Yazıcı wrote:
> Agreed with all points of Carter.
>
> It is
Agreed with all points of Carter.
It is either 1 or 4.
Anything more than 4 (including 5) is a hard no from me.
On Fri, Dec 24, 2021 at 6:00 PM Carter Kozak wrote:
> I would agree directionally with option 1 or option 4.
>
> Making changes without pushing binary artifacts to maven central (opti
Before any Pull Requests are reviewed this discussion needs to come to a
conclusion.
So far I have seen some people in favor of option 1, none in favor of option 2,
none in
favor of option 3, some in favor of option 1 or option 4, no one in favor of
option 5
(with several -1s) and Vladimir wh
this is a great summary of the options. I vote for option 2.
On Fri, 24 Dec 2021 at 16:47, Ralph Goers
wrote:
> As we all know Log4j 1.x reached end of life in August 2015. Log4j 1.2.17
> was released on May 26, 2012. The last commit was to update the
> web site 7 years ago. The changes.xml file
On Fri, Dec 24, 2021 at 5:21 PM Dominik Psenner wrote:
> I am in favor of option 1, basically this:
>
> * Add an EOL marker, big and bold
> * Allow the repository to be cloned
> * Allow the repository to be forked
> * Disable the creation of new pull requests (on github)
> * Disable creation of i
I am in favor of option 1, basically this:
* Add an EOL marker, big and bold
* Allow the repository to be cloned
* Allow the repository to be forked
* Disable the creation of new pull requests (on github)
* Disable creation of issues (on github; this is the default; I want to
stress this by mentio
I’d be in favor of 1 or 4. Option 5 isn’t very feasible right now evidenced by
how difficult it is to get enough votes on most of our other subproject
releases like log4net, log4cxx, Log4j Scala API, and Log4j Kotlin API. There’s
a long history in this PMC of wondering whether or not to continue
If I were to vote today it would probably be for option 1. I had a discussion
with another ASF member yesterday who reminded me that in projects
like Tomcat EOL means EOL. Once that date is hit under no circumstances will
they issue a new release.
However, I understand that there is a differenc
> On Dec 24, 2021, at 10:05 AM, Gary Gregory wrote:
>
>>
>
> What happens to the new repo Ralph created, will it just be deleted?
>
The request was to delete that repo. The request was to rename apache/log4j to
apache/logging-log4j1,
which is the same name as the repo I created.
Ralph
Thank you very much Ralph for compiling this list.
On Fri, Dec 24, 2021, at 17:47, Ralph Goers wrote:
> 1. Create a README.md that publishes the projects EOL status and do
> nothing else.
> 2. Create a README.md that says the project is EOL and no further big
> fixes or enhancements will be made
>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
>allow development to continue, including bug fixes and enhancements
+1 to all that, including new source
On Fri, Dec 24, 2021 at 12:13 PM Carter Kozak wrote:
> > Sorry to be pedantic, but what Apache rules apply to the previous
> DISCUSS/VOTE thread?
>
> There's no need to apologize, the rules exist for a reason!
>
> > It should be telling, not ironic, that the last two contributors to
> Log4j 1 tha
On Fri, Dec 24, 2021, at 18:12, Carter Kozak wrote:
>> Sorry to be pedantic, but what Apache rules apply to the previous
>> DISCUSS/VOTE thread?
>
> There's no need to apologize, the rules exist for a reason!
>
>> It should be telling, not ironic, that the last two contributors to Log4j 1
>> t
> Sorry to be pedantic, but what Apache rules apply to the previous
> DISCUSS/VOTE thread?
There's no need to apologize, the rules exist for a reason!
> It should be telling, not ironic, that the last two contributors to Log4j 1
> that are still here voted -1
This is a great point which I hadn
On Fri, Dec 24, 2021 at 11:47 AM Ralph Goers
wrote:
> As we all know Log4j 1.x reached end of life in August 2015. Log4j 1.2.17
> was released on May 26, 2012. The last commit was to update the
> web site 7 years ago. The changes.xml file shows there were commits up to
> sometime in 2012, all of
I would agree directionally with option 1 or option 4.
Making changes without pushing binary artifacts to maven central (options 2 and
3) is unlikely to do much good for the types of projects which still use
log4j1. Option 5 is a hard no from me, my time is already too constrained,
there are be
As we all know Log4j 1.x reached end of life in August 2015. Log4j 1.2.17 was
released on May 26, 2012. The last commit was to update the
web site 7 years ago. The changes.xml file shows there were commits up to
sometime in 2012, all of which were performed by Gary Gregory
and Christian Grobmei
17 matches
Mail list logo
