You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@logging.apache.org by Gary Gregory <ga...@gmail.com> on 2022/01/06 21:21:03 UTC
Re: [logging-log4j1] branch v1.2.8 created (now 0cde9dd)
-1 This component reached End-of-Life in 2015.
Gary
On Thu, Jan 6, 2022 at 12:46 PM <ce...@apache.org> wrote:
> This is an automated email from the ASF dual-hosted git repository.
>
> ceki pushed a change to branch v1.2.8
> in repository https://gitbox.apache.org/repos/asf/logging-log4j1.git.
>
>
> at 0cde9dd Add EOL message
>
> No new revisions were added by this update.
>
Re: [logging-log4j1] branch v1.2.8 created (now 0cde9dd)
Posted by Tim Perry <ti...@gmail.com>.
Maybe I'm missing something, but shouldn't it be 1.2.18? There was already
a log4j release 1.2.8 in 2005.
On Thu, Jan 6, 2022 at 2:54 PM Matt Sicker <bo...@gmail.com> wrote:
> Plus, the branch name sounds like a tag.
>
> On Thu, Jan 6, 2022 at 3:21 PM Gary Gregory <ga...@gmail.com>
> wrote:
> >
> > -1 This component reached End-of-Life in 2015.
> >
> > Gary
> >
> > On Thu, Jan 6, 2022 at 12:46 PM <ce...@apache.org> wrote:
> >
> > > This is an automated email from the ASF dual-hosted git repository.
> > >
> > > ceki pushed a change to branch v1.2.8
> > > in repository https://gitbox.apache.org/repos/asf/logging-log4j1.git.
> > >
> > >
> > > at 0cde9dd Add EOL message
> > >
> > > No new revisions were added by this update.
> > >
>
Re: [logging-log4j1] branch v1.2.8 created (now 0cde9dd)
Posted by Christian Grobmeier <gr...@apache.org>.
On Sat, Jan 8, 2022, at 05:11, Julius Davies wrote:
> One person's EOL is another person's open source business model ! (RHEL
> subscriptions are not cheap!)
I doubt anybody would actually pay for log4j.
>
> Anyway, quick FYI - I noticed Atlassian has rev'd log4j-1.2.17 fifteen
> times ! Might be some good patches in there. They do publish the
> "sources.jar":
> https://packages.atlassian.com/3rdparty/log4j/log4j/1.2.17-atlassian-15/
Didn’t look at the code, but I wonder why and what they did in those revs.
I got my customers to upgrade and still think this is what should be done. V1 has so many problems I am still confused people just don’t upgrade but stay with eol software.
>
>
> yours,
>
> Julius
>
>
>
>
> On Fri, Jan 7, 2022 at 11:59 AM Dominik Psenner <dp...@gmail.com> wrote:
>
>> End-Of-Life means End-Of-Life and that is the end of the story.
>>
>> If someone keeps patching an End-Of-Life component, how should downstream
>> understand when they should update their product?
>>
>> The answer to this question is the technical definition of End-Of-Life.
>>
>> Upgrade, migrate, rewrite, throw away, whatever, .. log4j1 builds on top of
>> End-Of-Life stuff like java 1.4 and has been dead for a decade.
>>
>> Stop living in the past, the future is now!
>> --
>> Sent from my phone. Typos are a kind gift to anyone who happens to find
>> them.
>>
>> On Fri, Jan 7, 2022, 19:38 Matt Sicker <bo...@gmail.com> wrote:
>>
>> > https://github.com/albfernandez/log4j/ is one fork I found that
>> > published a fixed copy on Maven Central. Confluent also publishes a
>> > forked copy, though I don't know where their source code is (package
>> > names are renamed as it's mainly used by old versions of Confluent's
>> > hosted services, so it's possible that the source code isn't
>> > published).
>> >
>> > One of the key missing pieces I've seen in other forks so far is that
>> > they simply ripped a lot of affected code out of the library entirely
>> > which is sure to cause compatibility issues when attempted to be used
>> > as a drop-in replacement. At least the patched versions in RHEL and
>> > Debian are mainly used by other RHEL or Debian packages, so they
>> > already have their own compatibility policies. While I'd imagine Ceki
>> > is one of the only people in the world who could figure out how to
>> > update the old build, it'd also be great to respond to relevant
>> > threads about this while they're active rather than waiting until
>> > after the bell rings. As Christian said, if the work is done outside
>> > the ASF to get a full release working for 1.2.x, then I think we'd be
>> > more receptive to accepting it back and making a release, especially
>> > if there is continued community interest in it. Otherwise, I still
>> > believe it's more useful to patch up the existing v2/v1 compatibility
>> > system so that users can drop in v2 to upgrade things much more
>> > easily, especially given the intractability of many concurrency issues
>> > in v1 that are fairly unacceptable in modern Java applications.
>> >
>> > On Fri, Jan 7, 2022 at 12:18 PM Andrew Marlow <ma...@gmail.com>
>> > wrote:
>> > >
>> > > my comment is below:
>> > >
>> > > On Fri, 7 Jan 2022 at 14:23, Christian Grobmeier <grobmeier@apache.org
>> >
>> > > wrote:
>> > >
>> > > > Hello,
>> > > >
>> > > > On Fri, Jan 7, 2022, at 08:21, Ceki Gülcü wrote:
>> > > > > As for infringing on the log4j trademark, I will rename the repo to
>> > > > > something else, for example "re4j".
>> > > > >
>> > > > > As mentioned in my previous message, if the ASF decides to
>> integrate
>> > > > > "re4j" as log4j 1.x, the door is open.
>> > > >
>> > > > Thanks. You did not respond to my earlier question why this is so
>> > urgent
>> > > > after 10 years,
>> > > > but I guess we see what you are trying to do on the fork.
>> > > >
>> > > > If we feel this is valuable, we may vote again. Thanks for keeping
>> that
>> > > > door open. I think working on a fork is the best way at this point of
>> > time.
>> > > >
>> > >
>> > > I want to add my thanks to Ceki as well. I would like to see log4j-v1
>> get
>> > > one fix in version 1.2.18 which RedHat have already made for RHEL7.
>> It's
>> > > the one for the SocketServer issue. The source for this fix is out
>> there
>> > > somewhere. I did track it down some time ago but I 've forgotten where
>> I
>> > > found it. Maybe Matt knows where it is, then it could be applied to
>> this
>> > > fork.
>> > >
>> > >
>> > > > Good luck.
>> > > >
>> > > > Kind regards,
>> > > > Christian
>> > > >
>> >
>>
Re: [logging-log4j1] branch v1.2.8 created (now 0cde9dd)
Posted by Julius Davies <ju...@gmail.com>.
One person's EOL is another person's open source business model ! (RHEL
subscriptions are not cheap!)
Anyway, quick FYI - I noticed Atlassian has rev'd log4j-1.2.17 fifteen
times ! Might be some good patches in there. They do publish the
"sources.jar":
https://packages.atlassian.com/3rdparty/log4j/log4j/1.2.17-atlassian-15/
yours,
Julius
On Fri, Jan 7, 2022 at 11:59 AM Dominik Psenner <dp...@gmail.com> wrote:
> End-Of-Life means End-Of-Life and that is the end of the story.
>
> If someone keeps patching an End-Of-Life component, how should downstream
> understand when they should update their product?
>
> The answer to this question is the technical definition of End-Of-Life.
>
> Upgrade, migrate, rewrite, throw away, whatever, .. log4j1 builds on top of
> End-Of-Life stuff like java 1.4 and has been dead for a decade.
>
> Stop living in the past, the future is now!
> --
> Sent from my phone. Typos are a kind gift to anyone who happens to find
> them.
>
> On Fri, Jan 7, 2022, 19:38 Matt Sicker <bo...@gmail.com> wrote:
>
> > https://github.com/albfernandez/log4j/ is one fork I found that
> > published a fixed copy on Maven Central. Confluent also publishes a
> > forked copy, though I don't know where their source code is (package
> > names are renamed as it's mainly used by old versions of Confluent's
> > hosted services, so it's possible that the source code isn't
> > published).
> >
> > One of the key missing pieces I've seen in other forks so far is that
> > they simply ripped a lot of affected code out of the library entirely
> > which is sure to cause compatibility issues when attempted to be used
> > as a drop-in replacement. At least the patched versions in RHEL and
> > Debian are mainly used by other RHEL or Debian packages, so they
> > already have their own compatibility policies. While I'd imagine Ceki
> > is one of the only people in the world who could figure out how to
> > update the old build, it'd also be great to respond to relevant
> > threads about this while they're active rather than waiting until
> > after the bell rings. As Christian said, if the work is done outside
> > the ASF to get a full release working for 1.2.x, then I think we'd be
> > more receptive to accepting it back and making a release, especially
> > if there is continued community interest in it. Otherwise, I still
> > believe it's more useful to patch up the existing v2/v1 compatibility
> > system so that users can drop in v2 to upgrade things much more
> > easily, especially given the intractability of many concurrency issues
> > in v1 that are fairly unacceptable in modern Java applications.
> >
> > On Fri, Jan 7, 2022 at 12:18 PM Andrew Marlow <ma...@gmail.com>
> > wrote:
> > >
> > > my comment is below:
> > >
> > > On Fri, 7 Jan 2022 at 14:23, Christian Grobmeier <grobmeier@apache.org
> >
> > > wrote:
> > >
> > > > Hello,
> > > >
> > > > On Fri, Jan 7, 2022, at 08:21, Ceki Gülcü wrote:
> > > > > As for infringing on the log4j trademark, I will rename the repo to
> > > > > something else, for example "re4j".
> > > > >
> > > > > As mentioned in my previous message, if the ASF decides to
> integrate
> > > > > "re4j" as log4j 1.x, the door is open.
> > > >
> > > > Thanks. You did not respond to my earlier question why this is so
> > urgent
> > > > after 10 years,
> > > > but I guess we see what you are trying to do on the fork.
> > > >
> > > > If we feel this is valuable, we may vote again. Thanks for keeping
> that
> > > > door open. I think working on a fork is the best way at this point of
> > time.
> > > >
> > >
> > > I want to add my thanks to Ceki as well. I would like to see log4j-v1
> get
> > > one fix in version 1.2.18 which RedHat have already made for RHEL7.
> It's
> > > the one for the SocketServer issue. The source for this fix is out
> there
> > > somewhere. I did track it down some time ago but I 've forgotten where
> I
> > > found it. Maybe Matt knows where it is, then it could be applied to
> this
> > > fork.
> > >
> > >
> > > > Good luck.
> > > >
> > > > Kind regards,
> > > > Christian
> > > >
> >
>
Re: [logging-log4j1] branch v1.2.8 created (now 0cde9dd)
Posted by Dominik Psenner <dp...@gmail.com>.
End-Of-Life means End-Of-Life and that is the end of the story.
If someone keeps patching an End-Of-Life component, how should downstream
understand when they should update their product?
The answer to this question is the technical definition of End-Of-Life.
Upgrade, migrate, rewrite, throw away, whatever, .. log4j1 builds on top of
End-Of-Life stuff like java 1.4 and has been dead for a decade.
Stop living in the past, the future is now!
--
Sent from my phone. Typos are a kind gift to anyone who happens to find
them.
On Fri, Jan 7, 2022, 19:38 Matt Sicker <bo...@gmail.com> wrote:
> https://github.com/albfernandez/log4j/ is one fork I found that
> published a fixed copy on Maven Central. Confluent also publishes a
> forked copy, though I don't know where their source code is (package
> names are renamed as it's mainly used by old versions of Confluent's
> hosted services, so it's possible that the source code isn't
> published).
>
> One of the key missing pieces I've seen in other forks so far is that
> they simply ripped a lot of affected code out of the library entirely
> which is sure to cause compatibility issues when attempted to be used
> as a drop-in replacement. At least the patched versions in RHEL and
> Debian are mainly used by other RHEL or Debian packages, so they
> already have their own compatibility policies. While I'd imagine Ceki
> is one of the only people in the world who could figure out how to
> update the old build, it'd also be great to respond to relevant
> threads about this while they're active rather than waiting until
> after the bell rings. As Christian said, if the work is done outside
> the ASF to get a full release working for 1.2.x, then I think we'd be
> more receptive to accepting it back and making a release, especially
> if there is continued community interest in it. Otherwise, I still
> believe it's more useful to patch up the existing v2/v1 compatibility
> system so that users can drop in v2 to upgrade things much more
> easily, especially given the intractability of many concurrency issues
> in v1 that are fairly unacceptable in modern Java applications.
>
> On Fri, Jan 7, 2022 at 12:18 PM Andrew Marlow <ma...@gmail.com>
> wrote:
> >
> > my comment is below:
> >
> > On Fri, 7 Jan 2022 at 14:23, Christian Grobmeier <gr...@apache.org>
> > wrote:
> >
> > > Hello,
> > >
> > > On Fri, Jan 7, 2022, at 08:21, Ceki Gülcü wrote:
> > > > As for infringing on the log4j trademark, I will rename the repo to
> > > > something else, for example "re4j".
> > > >
> > > > As mentioned in my previous message, if the ASF decides to integrate
> > > > "re4j" as log4j 1.x, the door is open.
> > >
> > > Thanks. You did not respond to my earlier question why this is so
> urgent
> > > after 10 years,
> > > but I guess we see what you are trying to do on the fork.
> > >
> > > If we feel this is valuable, we may vote again. Thanks for keeping that
> > > door open. I think working on a fork is the best way at this point of
> time.
> > >
> >
> > I want to add my thanks to Ceki as well. I would like to see log4j-v1 get
> > one fix in version 1.2.18 which RedHat have already made for RHEL7. It's
> > the one for the SocketServer issue. The source for this fix is out there
> > somewhere. I did track it down some time ago but I 've forgotten where I
> > found it. Maybe Matt knows where it is, then it could be applied to this
> > fork.
> >
> >
> > > Good luck.
> > >
> > > Kind regards,
> > > Christian
> > >
>
Re: [logging-log4j1] branch v1.2.8 created (now 0cde9dd)
Posted by Matt Sicker <bo...@gmail.com>.
https://github.com/albfernandez/log4j/ is one fork I found that
published a fixed copy on Maven Central. Confluent also publishes a
forked copy, though I don't know where their source code is (package
names are renamed as it's mainly used by old versions of Confluent's
hosted services, so it's possible that the source code isn't
published).
One of the key missing pieces I've seen in other forks so far is that
they simply ripped a lot of affected code out of the library entirely
which is sure to cause compatibility issues when attempted to be used
as a drop-in replacement. At least the patched versions in RHEL and
Debian are mainly used by other RHEL or Debian packages, so they
already have their own compatibility policies. While I'd imagine Ceki
is one of the only people in the world who could figure out how to
update the old build, it'd also be great to respond to relevant
threads about this while they're active rather than waiting until
after the bell rings. As Christian said, if the work is done outside
the ASF to get a full release working for 1.2.x, then I think we'd be
more receptive to accepting it back and making a release, especially
if there is continued community interest in it. Otherwise, I still
believe it's more useful to patch up the existing v2/v1 compatibility
system so that users can drop in v2 to upgrade things much more
easily, especially given the intractability of many concurrency issues
in v1 that are fairly unacceptable in modern Java applications.
On Fri, Jan 7, 2022 at 12:18 PM Andrew Marlow <ma...@gmail.com> wrote:
>
> my comment is below:
>
> On Fri, 7 Jan 2022 at 14:23, Christian Grobmeier <gr...@apache.org>
> wrote:
>
> > Hello,
> >
> > On Fri, Jan 7, 2022, at 08:21, Ceki Gülcü wrote:
> > > As for infringing on the log4j trademark, I will rename the repo to
> > > something else, for example "re4j".
> > >
> > > As mentioned in my previous message, if the ASF decides to integrate
> > > "re4j" as log4j 1.x, the door is open.
> >
> > Thanks. You did not respond to my earlier question why this is so urgent
> > after 10 years,
> > but I guess we see what you are trying to do on the fork.
> >
> > If we feel this is valuable, we may vote again. Thanks for keeping that
> > door open. I think working on a fork is the best way at this point of time.
> >
>
> I want to add my thanks to Ceki as well. I would like to see log4j-v1 get
> one fix in version 1.2.18 which RedHat have already made for RHEL7. It's
> the one for the SocketServer issue. The source for this fix is out there
> somewhere. I did track it down some time ago but I 've forgotten where I
> found it. Maybe Matt knows where it is, then it could be applied to this
> fork.
>
>
> > Good luck.
> >
> > Kind regards,
> > Christian
> >
Re: [logging-log4j1] branch v1.2.8 created (now 0cde9dd)
Posted by Andrew Marlow <ma...@gmail.com>.
my comment is below:
On Fri, 7 Jan 2022 at 14:23, Christian Grobmeier <gr...@apache.org>
wrote:
> Hello,
>
> On Fri, Jan 7, 2022, at 08:21, Ceki Gülcü wrote:
> > As for infringing on the log4j trademark, I will rename the repo to
> > something else, for example "re4j".
> >
> > As mentioned in my previous message, if the ASF decides to integrate
> > "re4j" as log4j 1.x, the door is open.
>
> Thanks. You did not respond to my earlier question why this is so urgent
> after 10 years,
> but I guess we see what you are trying to do on the fork.
>
> If we feel this is valuable, we may vote again. Thanks for keeping that
> door open. I think working on a fork is the best way at this point of time.
>
I want to add my thanks to Ceki as well. I would like to see log4j-v1 get
one fix in version 1.2.18 which RedHat have already made for RHEL7. It's
the one for the SocketServer issue. The source for this fix is out there
somewhere. I did track it down some time ago but I 've forgotten where I
found it. Maybe Matt knows where it is, then it could be applied to this
fork.
> Good luck.
>
> Kind regards,
> Christian
>
Re: [logging-log4j1] branch v1.2.8 created (now 0cde9dd)
Posted by Christian Grobmeier <gr...@apache.org>.
Hello,
On Fri, Jan 7, 2022, at 08:21, Ceki Gülcü wrote:
> As for infringing on the log4j trademark, I will rename the repo to
> something else, for example "re4j".
>
> As mentioned in my previous message, if the ASF decides to integrate
> "re4j" as log4j 1.x, the door is open.
Thanks. You did not respond to my earlier question why this is so urgent after 10 years,
but I guess we see what you are trying to do on the fork.
If we feel this is valuable, we may vote again. Thanks for keeping that door open. I think working on a fork is the best way at this point of time.
Good luck.
Kind regards,
Christian
>
> --
> Ceki Gülcü
>
>> —
>> Matt Sicker
>>
>>> On Jan 6, 2022, at 18:18, Ceki Gülcü <ce...@qos.ch> wrote:
>>>
>>>
>>>
>>> Hello all,
>>>
>>> Given the recent refusal to even consider work on a 1.2.18 branch, which would have been subject to PMC vote before release anyway, I have created a separate repository on github under the name "relog4j1". The intent of relog4j1 is to fix existing critical issues in log4j 1.x.
>>>
>>> If one day the logging PMC changes its mind and decides to integrate "relog4j1" as log4j 1.x, the door is open.
>>>
>>> Those interested to contribute, please contact me directly.
>>>
>>> Good luck and thanks for the fish.
>>> --
>>> Ceki Gülcü
>>>
Re: [logging-log4j1] branch v1.2.8 created (now 0cde9dd)
Posted by Ceki Gülcü <ce...@qos.ch>.
On 07/01/2022 01:53, Matt Sicker wrote:
> If you had left a comment back when we voted on the EOL status
> recently, then perhaps things would be different. Waiting until
> right after the second EOL announcement makes us seem like we
> just lied about said EOL status.
On 07/01/2022 02:46, Matt Sicker wrote:
> I should also note that naming a fork “relog4j” is confusingly
> similar to “log4j”. Please don’t infringe the trademark.
One would have hoped that the Logging PMC would vote to fix outstanding
critical issues in log4j 1.x and be done with it.
Instead, the PMC decided to reaffirm log4j 1.x EOL status even in the
presence of multiple ASF committers/members volunteering to do the work.
Ralph then stated that this was because those volunteers were not
existing log4j committers but since I had commit privileges, I could
volunteer, which I did.
I started working on branch log4j 1.2.18 and was vetoed down and had to
revert. That's fine.
No one in their right mind would accuse the PMC of lying about the EOL
status of log4j1.x. That is a formal decision which publicized for
everyone to see. Having said this, the current Logging PMC is creating
obstacles about the temporary revival of log4j 1.x. I don't see how you
could say otherwise.
As for infringing on the log4j trademark, I will rename the repo to
something else, for example "re4j".
As mentioned in my previous message, if the ASF decides to integrate
"re4j" as log4j 1.x, the door is open.
--
Ceki Gülcü
> —
> Matt Sicker
>
>> On Jan 6, 2022, at 18:18, Ceki Gülcü <ce...@qos.ch> wrote:
>>
>>
>>
>> Hello all,
>>
>> Given the recent refusal to even consider work on a 1.2.18 branch, which would have been subject to PMC vote before release anyway, I have created a separate repository on github under the name "relog4j1". The intent of relog4j1 is to fix existing critical issues in log4j 1.x.
>>
>> If one day the logging PMC changes its mind and decides to integrate "relog4j1" as log4j 1.x, the door is open.
>>
>> Those interested to contribute, please contact me directly.
>>
>> Good luck and thanks for the fish.
>> --
>> Ceki Gülcü
>>
Re: [logging-log4j1] branch v1.2.8 created (now 0cde9dd)
Posted by Matt Sicker <bo...@gmail.com>.
If you had left a comment back when we voted on the EOL status recently, then perhaps things would be different. Waiting until right after the second EOL announcement makes us seem like we just lied about said EOL status.
—
Matt Sicker
> On Jan 6, 2022, at 18:18, Ceki Gülcü <ce...@qos.ch> wrote:
>
>
>
> Hello all,
>
> Given the recent refusal to even consider work on a 1.2.18 branch, which would have been subject to PMC vote before release anyway, I have created a separate repository on github under the name "relog4j1". The intent of relog4j1 is to fix existing critical issues in log4j 1.x.
>
> If one day the logging PMC changes its mind and decides to integrate "relog4j1" as log4j 1.x, the door is open.
>
> Those interested to contribute, please contact me directly.
>
> Good luck and thanks for the fish.
> --
> Ceki Gülcü
>
>
>> On 07/01/2022 00:25, Ceki Gülcü wrote:
>>> On 07/01/2022 00:05, Ralph Goers wrote:
>>> Unless you can convince Gary to rescind his veto there is no choice but to revert.
>> Reverted in github.
Re: [logging-log4j1] branch v1.2.8 created (now 0cde9dd)
Posted by Matt Sicker <bo...@gmail.com>.
I should also note that naming a fork “relog4j” is confusingly similar to “log4j”. Please don’t infringe the trademark.
--
Matt Sicker
> On Jan 6, 2022, at 18:18, Ceki Gülcü <ce...@qos.ch> wrote:
>
>
>
> Hello all,
>
> Given the recent refusal to even consider work on a 1.2.18 branch, which would have been subject to PMC vote before release anyway, I have created a separate repository on github under the name "relog4j1". The intent of relog4j1 is to fix existing critical issues in log4j 1.x.
>
> If one day the logging PMC changes its mind and decides to integrate "relog4j1" as log4j 1.x, the door is open.
>
> Those interested to contribute, please contact me directly.
>
> Good luck and thanks for the fish.
> --
> Ceki Gülcü
>
>
> On 07/01/2022 00:25, Ceki Gülcü wrote:
>> On 07/01/2022 00:05, Ralph Goers wrote:
>>> Unless you can convince Gary to rescind his veto there is no choice but to revert.
>> Reverted in github.
Re: [logging-log4j1] branch v1.2.8 created (now 0cde9dd)
Posted by Ceki Gülcü <ce...@qos.ch>.
Hello all,
Given the recent refusal to even consider work on a 1.2.18 branch, which
would have been subject to PMC vote before release anyway, I have
created a separate repository on github under the name "relog4j1". The
intent of relog4j1 is to fix existing critical issues in log4j 1.x.
If one day the logging PMC changes its mind and decides to integrate
"relog4j1" as log4j 1.x, the door is open.
Those interested to contribute, please contact me directly.
Good luck and thanks for the fish.
--
Ceki Gülcü
On 07/01/2022 00:25, Ceki Gülcü wrote:
>
>
> On 07/01/2022 00:05, Ralph Goers wrote:
>
>> Unless you can convince Gary to rescind his veto there is no choice
>> but to revert.
>
> Reverted in github.
>
Re: [logging-log4j1] branch v1.2.8 created (now 0cde9dd)
Posted by Ceki Gülcü <ce...@qos.ch>.
On 07/01/2022 00:05, Ralph Goers wrote:
> Unless you can convince Gary to rescind his veto there is no choice but to revert.
Reverted in github.
--
Ceki Gülcü
Re: [logging-log4j1] branch v1.2.8 created (now 0cde9dd)
Posted by Ralph Goers <ra...@dslextreme.com>.
v1.2.8? Odd choice to work on 1.2.18.
However, with Gary expressing a -1 (a veto) by ASF rules the problem specified
(12 being EOL) would either need to be resolved or the commit reverted.
Unless you can convince Gary to rescind his veto there is no choice but to revert.
Ralph
> On Jan 6, 2022, at 3:54 PM, Matt Sicker <bo...@gmail.com> wrote:
>
> Plus, the branch name sounds like a tag.
>
> On Thu, Jan 6, 2022 at 3:21 PM Gary Gregory <ga...@gmail.com> wrote:
>>
>> -1 This component reached End-of-Life in 2015.
>>
>> Gary
>>
>> On Thu, Jan 6, 2022 at 12:46 PM <ce...@apache.org> wrote:
>>
>>> This is an automated email from the ASF dual-hosted git repository.
>>>
>>> ceki pushed a change to branch v1.2.8
>>> in repository https://gitbox.apache.org/repos/asf/logging-log4j1.git.
>>>
>>>
>>> at 0cde9dd Add EOL message
>>>
>>> No new revisions were added by this update.
>>>
>
Re: [logging-log4j1] branch v1.2.8 created (now 0cde9dd)
Posted by Matt Sicker <bo...@gmail.com>.
Plus, the branch name sounds like a tag.
On Thu, Jan 6, 2022 at 3:21 PM Gary Gregory <ga...@gmail.com> wrote:
>
> -1 This component reached End-of-Life in 2015.
>
> Gary
>
> On Thu, Jan 6, 2022 at 12:46 PM <ce...@apache.org> wrote:
>
> > This is an automated email from the ASF dual-hosted git repository.
> >
> > ceki pushed a change to branch v1.2.8
> > in repository https://gitbox.apache.org/repos/asf/logging-log4j1.git.
> >
> >
> > at 0cde9dd Add EOL message
> >
> > No new revisions were added by this update.
> >