Re: Looking for a champion: resurrect log4j 1.x

[Vladimir Sitnikov]

>Just wondering, is it even fulfilling the criteria of incubation?

I believe, the world does not need "active development in log4j 1.x"
nowadays.
What everybody needs from log4j 1.x is to fix security issues, fix
outstanding issues (if any),
keep the project buildable (e.g. avoid using outdated build systems), etc.

>it doesn't seem that sustainability is proven.

The problem is log4j 1.x is like COBOL of logging. There are apps that are
just stuck with log4j 1.x.
The proof of sustainability is that lots of existing apps will never
upgrade to 2.x because 2.x is incompatible.
If the compatibility layer of 2.x would be improved to handle 99.999% of
apps,
then we could indeed move 1.x to the attic.

The Incubator Cookbook says:
>The ASF provides software for the public good,

As I described, log4j 2.x is not a direct replacement for log4j 1.x, and
there are **lots** of applications
that can't easily be upgraded to 2.x due to testing, configuration, and
implementation issues.

The current Logging PMC is focused on log4j 2.x only, and they have no
desire to release 1.x

>active development but focus only on CVE fixes

I would say, the primary goal of resurrecting 1.x is to focus on CVEs, and
keep the project buildable and testable.
However, it might be the case, that certain fixes or features would appear.

The sad story is that the industry is using 1.x A LOT, and what Logging PMC
did was
they ignored the community, and they just stopped maintaining 1.x and
focused on an incompatible 2.x

Not only do they stop maintaining 1.x, but they also deny others to pick up
the maintenance task.

What I am trying to do now is to pick up that maintenance activity.

Vladimir

Re: [VOTE] Release Apache YuniKorn (Incubating) 0.12.1 (RC1)

[Xun Liu]

Hi,

+1 (binding) from me,

I have checked the following items:
- Incubating in name
- LICENSE and NOTICE are fine
- DISCLAIMER exists
- All links are valid
- No unexpected binary files
- All ASF files have ASF headers
- Checksums and PGP signatures are valid.
- Build from source in macOS
- Startup and run some RESTful tests,
   calls healthcheck successed.
- Deployed into KIND using helm charts and local build

Xun Liu
Best Regards,

On Tue, Dec 21, 2021 at 9:24 AM Chaoran Yu  wrote:

> Hello IPMC,
>
> The Apache YuniKorn community has voted and approved the release of Apache
> YuniKorn (incubating) 0.12.1 (RC1). We now kindly request IPMC members
> review and vote for this release.
>
> YuniKorn is a standalone, universal resource scheduler that can support
> both long-running and batch workloads. The current release offers
> enhancements and improvements in a number of areas: node sorting
> performance, gang scheduling, logging and observability, and scheduler
> interface. It also contains an upgraded Kubernetes dependency (v1.20) and
> now supports running on Kubernetes versions 1.19, 1.20 and 1.21.
>
> YuniKorn community vote thread:
> https://lists.apache.org/thread/1yr4y7tftth5bfxlxfy4l8gmo3ypk4d2 <
> https://lists.apache.org/thread/1yr4y7tftth5bfxlxfy4l8gmo3ypk4d2>
>
> Vote result thread:
> https://lists.apache.org/thread/z1f8wzx3t1n07qr8s4nfw224n74zryrs <
> https://lists.apache.org/thread/z1f8wzx3t1n07qr8s4nfw224n74zryrs>
>
> Issues included in this release:
> https://issues.apache.org/jira/projects/YUNIKORN/versions/12350843 <
> https://issues.apache.org/jira/projects/YUNIKORN/versions/12350843>
>
> The release candidate:
> https://dist.apache.org/repos/dist/dev/incubator/yunikorn/0.12.1/ <
> https://dist.apache.org/repos/dist/dev/incubator/yunikorn/0.12.1/>
>
> This release has been signed with a PGP available here (Fixed the link
> compared to the last voting email):
> https://downloads.apache.org/incubator/yunikorn/KEYS <
> https://downloads.apache.org/incubator/yunikorn/KEYS>
>
> Git tag for the release:
> - https://github.com/apache/incubator-yunikorn-core/tree/v0.12.1 <
> https://github.com/apache/incubator-yunikorn-core/tree/v0.12.1>
> - https://github.com/apache/incubator-yunikorn-k8shim/tree/v0.12.1 <
> https://github.com/apache/incubator-yunikorn-k8shim/tree/v0.12.1>
> -
> https://github.com/apache/incubator-yunikorn-scheduler-interface/tree/v0.12.1
> <
> https://github.com/apache/incubator-yunikorn-scheduler-interface/tree/v0.12.1>
>
> - https://github.com/apache/incubator-yunikorn-web/tree/v0.12.1 <
> https://github.com/apache/incubator-yunikorn-web/tree/v0.12.1>
>
> The vote will be open for at least 72 hours or until the necessary number
> of votes is reached.
>
> Please vote accordingly:
> [ ] +1 Approve the release of Apache YuniKorn (Incubating) 0.12.1
> [ ] +0
> [ ] -1 Do not approve (please specify the reason)
>
> Thanks,
> Chaoran Yu
> Apache YuniKorn (Incubating)

[VOTE] Release Apache YuniKorn (Incubating) 0.12.1 (RC1)

[Chaoran Yu]

Hello IPMC,

The Apache YuniKorn community has voted and approved the release of Apache 
YuniKorn (incubating) 0.12.1 (RC1). We now kindly request IPMC members review 
and vote for this release.

YuniKorn is a standalone, universal resource scheduler that can support both 
long-running and batch workloads. The current release offers enhancements and 
improvements in a number of areas: node sorting performance, gang scheduling, 
logging and observability, and scheduler interface. It also contains an 
upgraded Kubernetes dependency (v1.20) and now supports running on Kubernetes 
versions 1.19, 1.20 and 1.21.

YuniKorn community vote thread: 
https://lists.apache.org/thread/1yr4y7tftth5bfxlxfy4l8gmo3ypk4d2 
 

Vote result thread: 
https://lists.apache.org/thread/z1f8wzx3t1n07qr8s4nfw224n74zryrs 
 

Issues included in this release: 
https://issues.apache.org/jira/projects/YUNIKORN/versions/12350843 
 

The release candidate: 
https://dist.apache.org/repos/dist/dev/incubator/yunikorn/0.12.1/ 
 

This release has been signed with a PGP available here (Fixed the link compared 
to the last voting email): https://downloads.apache.org/incubator/yunikorn/KEYS 


Git tag for the release:
- https://github.com/apache/incubator-yunikorn-core/tree/v0.12.1 
 
- https://github.com/apache/incubator-yunikorn-k8shim/tree/v0.12.1 
 
- https://github.com/apache/incubator-yunikorn-scheduler-interface/tree/v0.12.1 
 
- https://github.com/apache/incubator-yunikorn-web/tree/v0.12.1 
 

The vote will be open for at least 72 hours or until the necessary number of 
votes is reached.

Please vote accordingly:
[ ] +1 Approve the release of Apache YuniKorn (Incubating) 0.12.1
[ ] +0
[ ] -1 Do not approve (please specify the reason)

Thanks,
Chaoran Yu
Apache YuniKorn (Incubating)

Re: Looking for a champion: resurrect log4j 1.x

[Felix Cheung]

What are the concerning security vulnerabilities in log4j 1 and the
severity level?

I saw one mentioned in the thread which apparently redhat had fixed (with
socket stream deserialization)


On Mon, Dec 20, 2021 at 3:56 PM Martin Gainty  wrote:

> i would ping the original author ceki gulcu
> Random thoughts by Ceki Gülcü: The forces and vulnerabilities of the
> Apache model<
> https://ceki.blogspot.com/2010/05/forces-and-vulnerabilites-of-apache.html
> >
> Random thoughts by Ceki Gülcü: The forces and vulnerabilities of the
> Apache model<
> https://ceki.blogspot.com/2010/05/forces-and-vulnerabilites-of-apache.html
> >
> Brett Porter said I agree with Bertrand's point. Also, it is necessary
> to be careful not to ascribe too much power to the votes themselves - they
> are only a tool for gauging consensus, which is the main objective.
> ceki.blogspot.com
>
> Best Regards,
> martin-
>
> 
> From: Jungtaek Lim 
> Sent: Monday, December 20, 2021 4:26 PM
> To: general@incubator.apache.org 
> Subject: Re: Looking for a champion: resurrect log4j 1.x
>
> Just wondering, is it even fulfilling the criteria of incubation? Have
> there been any similar cases before?
>
> It was stated that there will be no effort on active development but focus
> only on CVE fixes. This sounds to me as the project will start as only
> fixing a few known CVEs and stop till other CVEs are discovered (there may
> be huge difference between proactively discovering CVEs vs passively fixing
> the reported CVEs by others), and never be attempted to become TLP.
> Majority of status reports will be blank. That said, it doesn't seem that
> sustainability is proven.
>
>
> On Mon, Dec 20, 2021 at 10:51 PM John D. Ament 
> wrote:
>
> > On Mon, Dec 20, 2021 at 8:42 AM Romain Manni-Bucau <
> rmannibu...@gmail.com>
> > wrote:
> >
> > > Guess there are 4 options:
> > >
> > > 1. resurrect log4j1 and let it die again
> > > 2. do a log4j1 release for the CVE under logging umbrella (as a
> > subproject)
> > > - after all log4j1 belongs to logging as a subproject already (
> > > https://logging.apache.org/dormant.html)
> > > 3. the log4j1-log4j2 bridge (but agree this is not a solution and
> > requires
> > > to do 2 to be useful technically since none of log4j1 users will want
> to
> > > import log4j2, at least cause it is not compatible with java version or
> > due
> > > to the injected bytecode like module-info)
> > > 4. do a CVE fix release fork on github or any other hosting
> > >
> > > Personally I don't think 1 or 3 are real options, 4 is but not that
> nice
> > > indeed (due to the fact it would be yet another forks but also cause it
> > > requires some GAV change or build hack to be done properly) so from my
> > > window I would be tempted to push for 2 which sounds like a quick win
> for
> > > everyone.
> > >
> >
> > Questions like this probably should be on one of the logging lists rather
> > than the incubator list.  The Incubator would not create a hostile fork
> > under any circumstance, including of an existing project/sub-project
> within
> > Apache.  In a situation like this it would be purely a call by the
> Logging
> > PMC, whether or not they want the Incubator to create the podling.
> >
> >
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau  |  Blog
> > >  | Old Blog
> > >  | Github <
> > > https://github.com/rmannibucau> |
> > > LinkedIn  | Book
> > > <
> > >
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > >
> > >
> > >
> > > Le lun. 20 déc. 2021 à 14:32, John D. Ament  a
> > > écrit :
> > >
> > > > Hi Vladimir,
> > > >
> > > > I think based on what you're describing and the Logging PMC's
> response,
> > > > re-incubating the project makes sense.  I would be curious if the
> > Logging
> > > > PMC would be interested in restarting the sub-project after a
> > successful
> > > > incubation period.  This seems to match what Ralph is suggesting as
> > well.
> > > >
> > > > Typically this would mean that the VP Logging PMC would serve as the
> > > > champion, and as the sponsor the Logging PMC would still be the one
> to
> > > vote
> > > > to add the project to the incubator.  If the VP Logging isn't
> > interested
> > > in
> > > > doing this, I would recommend starting out the project as a
> standalone
> > > > podling and keeping the Incubator as sponsor rather than Logging.
> See
> > > [1]
> > > > for some details on those notes.  The incubator would be responsible
> > for
> > > > voting on releases, receiving notices for new PPMC members, etc
> > > regardless
> > > > of who is the sponsor.  Given enough contributors and a diverse
> > > contributor
> > > > base then the Incubator PMC and the Logging PMC (if they're the
> > sponsor)
> > > > would vote whether everyone feels the new project can be brought back
> > to
> > > > 

Re: Looking for a champion: resurrect log4j 1.x

[Martin Gainty]

i would ping the original author ceki gulcu
Random thoughts by Ceki Gülcü: The forces and vulnerabilities of the Apache 
model
Random thoughts by Ceki Gülcü: The forces and vulnerabilities of the Apache 
model
Brett Porter said I agree with Bertrand's point. Also, it is necessary to 
be careful not to ascribe too much power to the votes themselves - they are 
only a tool for gauging consensus, which is the main objective.
ceki.blogspot.com

Best Regards,
martin-


From: Jungtaek Lim 
Sent: Monday, December 20, 2021 4:26 PM
To: general@incubator.apache.org 
Subject: Re: Looking for a champion: resurrect log4j 1.x

Just wondering, is it even fulfilling the criteria of incubation? Have
there been any similar cases before?

It was stated that there will be no effort on active development but focus
only on CVE fixes. This sounds to me as the project will start as only
fixing a few known CVEs and stop till other CVEs are discovered (there may
be huge difference between proactively discovering CVEs vs passively fixing
the reported CVEs by others), and never be attempted to become TLP.
Majority of status reports will be blank. That said, it doesn't seem that
sustainability is proven.


On Mon, Dec 20, 2021 at 10:51 PM John D. Ament 
wrote:

> On Mon, Dec 20, 2021 at 8:42 AM Romain Manni-Bucau 
> wrote:
>
> > Guess there are 4 options:
> >
> > 1. resurrect log4j1 and let it die again
> > 2. do a log4j1 release for the CVE under logging umbrella (as a
> subproject)
> > - after all log4j1 belongs to logging as a subproject already (
> > https://logging.apache.org/dormant.html)
> > 3. the log4j1-log4j2 bridge (but agree this is not a solution and
> requires
> > to do 2 to be useful technically since none of log4j1 users will want to
> > import log4j2, at least cause it is not compatible with java version or
> due
> > to the injected bytecode like module-info)
> > 4. do a CVE fix release fork on github or any other hosting
> >
> > Personally I don't think 1 or 3 are real options, 4 is but not that nice
> > indeed (due to the fact it would be yet another forks but also cause it
> > requires some GAV change or build hack to be done properly) so from my
> > window I would be tempted to push for 2 which sounds like a quick win for
> > everyone.
> >
>
> Questions like this probably should be on one of the logging lists rather
> than the incubator list.  The Incubator would not create a hostile fork
> under any circumstance, including of an existing project/sub-project within
> Apache.  In a situation like this it would be purely a call by the Logging
> PMC, whether or not they want the Incubator to create the podling.
>
>
> >
> > Romain Manni-Bucau
> > @rmannibucau  |  Blog
> >  | Old Blog
> >  | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn  | Book
> > <
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> >
> >
> > Le lun. 20 déc. 2021 à 14:32, John D. Ament  a
> > écrit :
> >
> > > Hi Vladimir,
> > >
> > > I think based on what you're describing and the Logging PMC's response,
> > > re-incubating the project makes sense.  I would be curious if the
> Logging
> > > PMC would be interested in restarting the sub-project after a
> successful
> > > incubation period.  This seems to match what Ralph is suggesting as
> well.
> > >
> > > Typically this would mean that the VP Logging PMC would serve as the
> > > champion, and as the sponsor the Logging PMC would still be the one to
> > vote
> > > to add the project to the incubator.  If the VP Logging isn't
> interested
> > in
> > > doing this, I would recommend starting out the project as a standalone
> > > podling and keeping the Incubator as sponsor rather than Logging.  See
> > [1]
> > > for some details on those notes.  The incubator would be responsible
> for
> > > voting on releases, receiving notices for new PPMC members, etc
> > regardless
> > > of who is the sponsor.  Given enough contributors and a diverse
> > contributor
> > > base then the Incubator PMC and the Logging PMC (if they're the
> sponsor)
> > > would vote whether everyone feels the new project can be brought back
> to
> > > the Logging project.  We can also decide as it gets closer to
> graduation
> > to
> > > move the podling into a sub-project if that's what everyone agrees.
> > >
> > > I would be up for helping you get through the incubator.  If VP Logging
> > > doesn't want to own the sponsorship part, I can be your Champion.
> > >
> > > John
> > >
> > >
> > > [1]: https://incubator.apache.org/guides/proposal.html#background
> > >
> > > On Mon, Dec 20, 2021 at 8:20 AM Vladimir Sitnikov <
> > > sitnikov.vladi...@gmail.com> 

Re: [VOTE] Release Apache YuniKorn (Incubating) 0.12.1 (RC1)

[sebb]

On Mon, 20 Dec 2021 at 17:43, Chaoran Yu  wrote:
>
> Hi Sebb,
>
> Thanks for the pointer. We have removed the keys from the dev location. Now 
> my key is only present at 
> https://downloads.apache.org/incubator/yunikorn/KEYS.

Please re-issue the VOTE thread with the correct URL.

>
> On 2021/12/20 11:29:36 sebb wrote:
> > On Mon, 20 Dec 2021 at 04:29, Chaoran Yu  wrote:
> > >
> > > Hello IPMC,
> > >
> > > The Apache YuniKorn community has voted and approved the release of 
> > > Apache YuniKorn (incubating) 0.12.1 (RC1). We now kindly request IPMC 
> > > members review and vote for this release.
> > >
> > > YuniKorn is a standalone, universal resource scheduler that can support 
> > > both long-running and batch workloads. The current release offers 
> > > enhancements and improvements in a number of areas: node sorting 
> > > performance, gang scheduling, logging and observability, and scheduler 
> > > interface. It also contains an upgraded Kubernetes dependency (v1.20) and 
> > > now supports running on Kubernetes versions 1.19, 1.20 and 1.21.
> > >
> > > YuniKorn community vote thread: 
> > > https://lists.apache.org/thread/1yr4y7tftth5bfxlxfy4l8gmo3ypk4d2 
> > > 
> > >
> > > Vote result thread: 
> > > https://lists.apache.org/thread/z1f8wzx3t1n07qr8s4nfw224n74zryrs 
> > > 
> > >
> > > Issues included in this release: 
> > > https://issues.apache.org/jira/projects/YUNIKORN/versions/12350843 
> > > 
> > >
> > > The release candidate: 
> > > https://dist.apache.org/repos/dist/dev/incubator/yunikorn/0.12.1/ 
> > > 
> > >
> > > This release has been signed with a PGP available here: 
> > > https://dist.apache.org/repos/dist/dev/incubator/yunikorn/KEYS 
> > > 
> >
> > -1
> >
> > Please do NOT use the above URL for KEYS.
> >
> > Only use
> >
> > https://downloads.apache.org/incubator/yunikorn/KEYS
> >
> > For the reasons why, please read recent emails to this list.
> > There have been several about the same issue.
> >
> > > Git tag for the release:
> > > - https://github.com/apache/incubator-yunikorn-core/tree/v0.12.1 
> > > 
> > > - https://github.com/apache/incubator-yunikorn-k8shim/tree/v0.12.1 
> > > 
> > > - 
> > > https://github.com/apache/incubator-yunikorn-scheduler-interface/tree/v0.12.1
> > >  
> > > 
> > > - https://github.com/apache/incubator-yunikorn-web/tree/v0.12.1 
> > > 
> > >
> > > The vote will be open for at least 72 hours or until the necessary number 
> > > of votes is reached.
> > >
> > > Please vote accordingly:
> > > [ ] +1 Approve the release of Apache YuniKorn (Incubating) 0.12.1
> > > [ ] +0
> > > [ ] -1 Do not approve (please specify the reason)
> > >
> > > Thanks,
> > > Chaoran Yu
> > > Apache YuniKorn (Incubating)
> > >
> > >
> >
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
> >
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [DISCUSS] Graduate Apache AGE Incubating as a Top Level Project

[Eya Badal Abdisho]

Hello Justin,

Thank you for your feedback. Please find more information following:

- Indications that the committer/PPMC bar may be too high and not all forms
of contribution recognized → Comment noted. We will no longer insist that
committers are code contributors.

- A new PPMC member is not being added in the correct way → Are there any
additional steps that need to be taken to complete this process?

- Other than that recent addition no other PPMC members added → The voting
process for Pieterjan De Potter (Ghent University) and Nick Sorrell (Cintio
Ltd) to become PPMC members will begin immediately.

- May be some concern about the employment diversity of the PPMC members.

The proposed new PPMC members above are not affiliated with any other PPMC
in any way.



   -

   John Gemignani [Bitnine] → Initial member of the project at the time of
   donation
   -

   Josh Innis [Bitnine] → Initial member of the project at the time of
   donation
   -

   Eya Badal [Bitnine] → Initial member of the project at the time of
   donation
   -

   Mason Sharp [Immuta] → Initial member of the project at the time of
   donation
   -

   Jasper Blues [Libration Data] → Initial member of the project at the
   time of donation
   -

   Dehowe Feng [Bitnine]
   -

   Pieterjan De Potter [Ghent university] → Soon to be PPMC
   -

   Nick Sorrell [Cintio] → Soon to be PPMC


- Issues with headers and licensing a few months back → All were fixed at
the time when 0.6.0 was released.


-People not signed up to the right mailing lists → All the active people
did. Jasper (initial member) and Mason (initial member) have been mainly
following and supporting the project and will sign up to the mailing lists.
Raphael (mentor) and Suneel (mentor) have not been active at all.

- I see in the maturity guide under releases it mentions docker files but
these don’t seem to be documented on the website? Where are these located?
This related JIRA is a little concerning [1].
The docker image is available at
https://hub.docker.com/repository/docker/joefagan/incubator-age and a link
is provided on the website on the Releases page. The image (>800MB) cannot
reside on age.apache.org because it exceeds the file size limit of 25MB.

- There are some minor trademark issues on the Bitnine site e.g [2] → All
will be fixed in a day.

- Releases of Age-viewer not following ASF policy → The first official
Apache release for the Age-viewer is in the voting process and it follows
the ASF policy.

- Links to download 0.5.0 and 0.6.0 on the download page are not correct
[3] They are fixed now

- I notice one person who replied to this thread had a agedb.io email
address - what is it relationship with the project?

Agedb is a US startup (incorporated in California May this year) and is
affiliated with Bitnine Global, who contributed the original AGE source
codes to the Apache Software Foundation. The purpose of Agedb is not yet
clearly defined but it is expected to be to provide graph database
solutions and related services.

The agedb.io email address belongs to Andrew Ko (also a consultant to
Bitnine) who is one of the committers. He has been helping the project,
consulting on the roadmap and website, and nurturing technical
collaboration with other Big Data related Apache projects.

Thank you very much again for your time and support.
Eya


On Sat, Dec 18, 2021 at 3:55 AM Justin Mclean 
wrote:

> Hi,
>
> > Because of the nature of the project, committers require a broad range of
> > expertise in several areas including: Database (Postgres and SQL), Graph
> > Technology and Cyper, C language. While many contributors demonstrated
> > expertise in some areas, few had expertise in all disciplines. In
> addition
> > we restricted committer status to those who demonstrated consistent
> > contribution to the project over many months and across multiple and
> > diverse challenges. We felt this was the most prudent way to build a
> strong
> > and tight community.
>
> IMO that bar is far too high, and I suggest the project needs to lower its
> bar. No one should have to be an expert in all areas to become a committer
> in a project. It would also be best to consider committers than contribute
> things other than code.
>
> Kind Regards,
> Justin
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

-- 

Bitnine Global, Inc. - We create value for our clients by connecting the
world's data.


*Eya Badal Abdisho*

Technical Engineer

E-mail : eya.abdi...@bitnine.net 

Mobile : +1 408-966-3301

3945 Freedom Cir., Suite 260,
Santa Clara, CA 95054

www.bitnine.net

Re: Looking for a champion: resurrect log4j 1.x

[Jungtaek Lim]

Just wondering, is it even fulfilling the criteria of incubation? Have
there been any similar cases before?

It was stated that there will be no effort on active development but focus
only on CVE fixes. This sounds to me as the project will start as only
fixing a few known CVEs and stop till other CVEs are discovered (there may
be huge difference between proactively discovering CVEs vs passively fixing
the reported CVEs by others), and never be attempted to become TLP.
Majority of status reports will be blank. That said, it doesn't seem that
sustainability is proven.


On Mon, Dec 20, 2021 at 10:51 PM John D. Ament 
wrote:

> On Mon, Dec 20, 2021 at 8:42 AM Romain Manni-Bucau 
> wrote:
>
> > Guess there are 4 options:
> >
> > 1. resurrect log4j1 and let it die again
> > 2. do a log4j1 release for the CVE under logging umbrella (as a
> subproject)
> > - after all log4j1 belongs to logging as a subproject already (
> > https://logging.apache.org/dormant.html)
> > 3. the log4j1-log4j2 bridge (but agree this is not a solution and
> requires
> > to do 2 to be useful technically since none of log4j1 users will want to
> > import log4j2, at least cause it is not compatible with java version or
> due
> > to the injected bytecode like module-info)
> > 4. do a CVE fix release fork on github or any other hosting
> >
> > Personally I don't think 1 or 3 are real options, 4 is but not that nice
> > indeed (due to the fact it would be yet another forks but also cause it
> > requires some GAV change or build hack to be done properly) so from my
> > window I would be tempted to push for 2 which sounds like a quick win for
> > everyone.
> >
>
> Questions like this probably should be on one of the logging lists rather
> than the incubator list.  The Incubator would not create a hostile fork
> under any circumstance, including of an existing project/sub-project within
> Apache.  In a situation like this it would be purely a call by the Logging
> PMC, whether or not they want the Incubator to create the podling.
>
>
> >
> > Romain Manni-Bucau
> > @rmannibucau  |  Blog
> >  | Old Blog
> >  | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn  | Book
> > <
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > >
> >
> >
> > Le lun. 20 déc. 2021 à 14:32, John D. Ament  a
> > écrit :
> >
> > > Hi Vladimir,
> > >
> > > I think based on what you're describing and the Logging PMC's response,
> > > re-incubating the project makes sense.  I would be curious if the
> Logging
> > > PMC would be interested in restarting the sub-project after a
> successful
> > > incubation period.  This seems to match what Ralph is suggesting as
> well.
> > >
> > > Typically this would mean that the VP Logging PMC would serve as the
> > > champion, and as the sponsor the Logging PMC would still be the one to
> > vote
> > > to add the project to the incubator.  If the VP Logging isn't
> interested
> > in
> > > doing this, I would recommend starting out the project as a standalone
> > > podling and keeping the Incubator as sponsor rather than Logging.  See
> > [1]
> > > for some details on those notes.  The incubator would be responsible
> for
> > > voting on releases, receiving notices for new PPMC members, etc
> > regardless
> > > of who is the sponsor.  Given enough contributors and a diverse
> > contributor
> > > base then the Incubator PMC and the Logging PMC (if they're the
> sponsor)
> > > would vote whether everyone feels the new project can be brought back
> to
> > > the Logging project.  We can also decide as it gets closer to
> graduation
> > to
> > > move the podling into a sub-project if that's what everyone agrees.
> > >
> > > I would be up for helping you get through the incubator.  If VP Logging
> > > doesn't want to own the sponsorship part, I can be your Champion.
> > >
> > > John
> > >
> > >
> > > [1]: https://incubator.apache.org/guides/proposal.html#background
> > >
> > > On Mon, Dec 20, 2021 at 8:20 AM Vladimir Sitnikov <
> > > sitnikov.vladi...@gmail.com> wrote:
> > >
> > > > >Do you have "facts" (like message on mailing list) ?
> > > >
> > > > I am not sure what you mean.
> > > >
> > > > For example:
> > > >
> > > > 1) Ralph Goers says the existing committers did not touch 1.x code a
> > lot:
> > > > https://lists.apache.org/thread/j6zrdp1d148qpkg0g7x3cc41o070oq6n
> > > > Ralph>Virtually all of the contributors to the Log4j 1.x project
> left a
> > > few
> > > > years before it was declared
> > > > Ralph>EOL. That is the primary reason it was retired. Although the
> > > current
> > > > set of committers have
> > > > Ralph>access to the code, none of us have ever built it
> > > >
> > > > 2) Ralph Goers (a member of Logging PMC) suggested that one of the
> ways
> > > to
> > > > move forward is to re-incubate log4j 1.x:
> > > > 

Re: [VOTE] Release Apache YuniKorn (Incubating) 0.12.1 (RC1)

[Chaoran Yu]

Hi Sebb,

Thanks for the pointer. We have removed the keys from the dev location. Now my 
key is only present at https://downloads.apache.org/incubator/yunikorn/KEYS.


On 2021/12/20 11:29:36 sebb wrote:
> On Mon, 20 Dec 2021 at 04:29, Chaoran Yu  wrote:
> >
> > Hello IPMC,
> >
> > The Apache YuniKorn community has voted and approved the release of Apache 
> > YuniKorn (incubating) 0.12.1 (RC1). We now kindly request IPMC members 
> > review and vote for this release.
> >
> > YuniKorn is a standalone, universal resource scheduler that can support 
> > both long-running and batch workloads. The current release offers 
> > enhancements and improvements in a number of areas: node sorting 
> > performance, gang scheduling, logging and observability, and scheduler 
> > interface. It also contains an upgraded Kubernetes dependency (v1.20) and 
> > now supports running on Kubernetes versions 1.19, 1.20 and 1.21.
> >
> > YuniKorn community vote thread: 
> > https://lists.apache.org/thread/1yr4y7tftth5bfxlxfy4l8gmo3ypk4d2 
> > 
> >
> > Vote result thread: 
> > https://lists.apache.org/thread/z1f8wzx3t1n07qr8s4nfw224n74zryrs 
> > 
> >
> > Issues included in this release: 
> > https://issues.apache.org/jira/projects/YUNIKORN/versions/12350843 
> > 
> >
> > The release candidate: 
> > https://dist.apache.org/repos/dist/dev/incubator/yunikorn/0.12.1/ 
> > 
> >
> > This release has been signed with a PGP available here: 
> > https://dist.apache.org/repos/dist/dev/incubator/yunikorn/KEYS 
> > 
> 
> -1
> 
> Please do NOT use the above URL for KEYS.
> 
> Only use
> 
> https://downloads.apache.org/incubator/yunikorn/KEYS
> 
> For the reasons why, please read recent emails to this list.
> There have been several about the same issue.
> 
> > Git tag for the release:
> > - https://github.com/apache/incubator-yunikorn-core/tree/v0.12.1 
> > 
> > - https://github.com/apache/incubator-yunikorn-k8shim/tree/v0.12.1 
> > 
> > - 
> > https://github.com/apache/incubator-yunikorn-scheduler-interface/tree/v0.12.1
> >  
> > 
> > - https://github.com/apache/incubator-yunikorn-web/tree/v0.12.1 
> > 
> >
> > The vote will be open for at least 72 hours or until the necessary number 
> > of votes is reached.
> >
> > Please vote accordingly:
> > [ ] +1 Approve the release of Apache YuniKorn (Incubating) 0.12.1
> > [ ] +0
> > [ ] -1 Do not approve (please specify the reason)
> >
> > Thanks,
> > Chaoran Yu
> > Apache YuniKorn (Incubating)
> >
> >
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 
> 

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Looking for a champion: resurrect log4j 1.x

[John D. Ament]

On Mon, Dec 20, 2021 at 8:42 AM Romain Manni-Bucau 
wrote:

> Guess there are 4 options:
>
> 1. resurrect log4j1 and let it die again
> 2. do a log4j1 release for the CVE under logging umbrella (as a subproject)
> - after all log4j1 belongs to logging as a subproject already (
> https://logging.apache.org/dormant.html)
> 3. the log4j1-log4j2 bridge (but agree this is not a solution and requires
> to do 2 to be useful technically since none of log4j1 users will want to
> import log4j2, at least cause it is not compatible with java version or due
> to the injected bytecode like module-info)
> 4. do a CVE fix release fork on github or any other hosting
>
> Personally I don't think 1 or 3 are real options, 4 is but not that nice
> indeed (due to the fact it would be yet another forks but also cause it
> requires some GAV change or build hack to be done properly) so from my
> window I would be tempted to push for 2 which sounds like a quick win for
> everyone.
>

Questions like this probably should be on one of the logging lists rather
than the incubator list.  The Incubator would not create a hostile fork
under any circumstance, including of an existing project/sub-project within
Apache.  In a situation like this it would be purely a call by the Logging
PMC, whether or not they want the Incubator to create the podling.


>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github <
> https://github.com/rmannibucau> |
> LinkedIn  | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le lun. 20 déc. 2021 à 14:32, John D. Ament  a
> écrit :
>
> > Hi Vladimir,
> >
> > I think based on what you're describing and the Logging PMC's response,
> > re-incubating the project makes sense.  I would be curious if the Logging
> > PMC would be interested in restarting the sub-project after a successful
> > incubation period.  This seems to match what Ralph is suggesting as well.
> >
> > Typically this would mean that the VP Logging PMC would serve as the
> > champion, and as the sponsor the Logging PMC would still be the one to
> vote
> > to add the project to the incubator.  If the VP Logging isn't interested
> in
> > doing this, I would recommend starting out the project as a standalone
> > podling and keeping the Incubator as sponsor rather than Logging.  See
> [1]
> > for some details on those notes.  The incubator would be responsible for
> > voting on releases, receiving notices for new PPMC members, etc
> regardless
> > of who is the sponsor.  Given enough contributors and a diverse
> contributor
> > base then the Incubator PMC and the Logging PMC (if they're the sponsor)
> > would vote whether everyone feels the new project can be brought back to
> > the Logging project.  We can also decide as it gets closer to graduation
> to
> > move the podling into a sub-project if that's what everyone agrees.
> >
> > I would be up for helping you get through the incubator.  If VP Logging
> > doesn't want to own the sponsorship part, I can be your Champion.
> >
> > John
> >
> >
> > [1]: https://incubator.apache.org/guides/proposal.html#background
> >
> > On Mon, Dec 20, 2021 at 8:20 AM Vladimir Sitnikov <
> > sitnikov.vladi...@gmail.com> wrote:
> >
> > > >Do you have "facts" (like message on mailing list) ?
> > >
> > > I am not sure what you mean.
> > >
> > > For example:
> > >
> > > 1) Ralph Goers says the existing committers did not touch 1.x code a
> lot:
> > > https://lists.apache.org/thread/j6zrdp1d148qpkg0g7x3cc41o070oq6n
> > > Ralph>Virtually all of the contributors to the Log4j 1.x project left a
> > few
> > > years before it was declared
> > > Ralph>EOL. That is the primary reason it was retired. Although the
> > current
> > > set of committers have
> > > Ralph>access to the code, none of us have ever built it
> > >
> > > 2) Ralph Goers (a member of Logging PMC) suggested that one of the ways
> > to
> > > move forward is to re-incubate log4j 1.x:
> > > https://lists.apache.org/thread/mlpb9v15r8qzpc58xnjn99r6tf9yy0p5
> > >
> > > This in conjunction with #1 sounds like the current logging PMC is not
> > > interested in moving log4j 1.x forward.
> > >
> > > 3) I suggest moving log4j 1.x to Git, and nobody from PMC approves the
> > > change;
> > > Gary Gregory (a member of Logging PMC) votes with -1 (binding):
> > > https://lists.apache.org/thread/y89v84okzs76g2yl760vx5yc0w1y4yd8
> > >
> > > 4) Both Gary and Mike push for "improving log4j 1->2 compatibility
> > layer":
> > > https://lists.apache.org/thread/hq2m11f1w9yp031r5f65b9h4ym2zy1kc
> > > https://lists.apache.org/thread/tw172svxt1q6wds7lt9szyjw2sxjf34n
> > >
> > > I understand that log4j2 team might want everybody to upgrade to 2.x,
> > > however, that is not possible since the apps would need significant
> > > regression testing,
> > > the compatibility layer is far from 

Re: Looking for a champion: resurrect log4j 1.x

[Romain Manni-Bucau]

Guess there are 4 options:

1. resurrect log4j1 and let it die again
2. do a log4j1 release for the CVE under logging umbrella (as a subproject)
- after all log4j1 belongs to logging as a subproject already (
https://logging.apache.org/dormant.html)
3. the log4j1-log4j2 bridge (but agree this is not a solution and requires
to do 2 to be useful technically since none of log4j1 users will want to
import log4j2, at least cause it is not compatible with java version or due
to the injected bytecode like module-info)
4. do a CVE fix release fork on github or any other hosting

Personally I don't think 1 or 3 are real options, 4 is but not that nice
indeed (due to the fact it would be yet another forks but also cause it
requires some GAV change or build hack to be done properly) so from my
window I would be tempted to push for 2 which sounds like a quick win for
everyone.

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le lun. 20 déc. 2021 à 14:32, John D. Ament  a
écrit :

> Hi Vladimir,
>
> I think based on what you're describing and the Logging PMC's response,
> re-incubating the project makes sense.  I would be curious if the Logging
> PMC would be interested in restarting the sub-project after a successful
> incubation period.  This seems to match what Ralph is suggesting as well.
>
> Typically this would mean that the VP Logging PMC would serve as the
> champion, and as the sponsor the Logging PMC would still be the one to vote
> to add the project to the incubator.  If the VP Logging isn't interested in
> doing this, I would recommend starting out the project as a standalone
> podling and keeping the Incubator as sponsor rather than Logging.  See [1]
> for some details on those notes.  The incubator would be responsible for
> voting on releases, receiving notices for new PPMC members, etc regardless
> of who is the sponsor.  Given enough contributors and a diverse contributor
> base then the Incubator PMC and the Logging PMC (if they're the sponsor)
> would vote whether everyone feels the new project can be brought back to
> the Logging project.  We can also decide as it gets closer to graduation to
> move the podling into a sub-project if that's what everyone agrees.
>
> I would be up for helping you get through the incubator.  If VP Logging
> doesn't want to own the sponsorship part, I can be your Champion.
>
> John
>
>
> [1]: https://incubator.apache.org/guides/proposal.html#background
>
> On Mon, Dec 20, 2021 at 8:20 AM Vladimir Sitnikov <
> sitnikov.vladi...@gmail.com> wrote:
>
> > >Do you have "facts" (like message on mailing list) ?
> >
> > I am not sure what you mean.
> >
> > For example:
> >
> > 1) Ralph Goers says the existing committers did not touch 1.x code a lot:
> > https://lists.apache.org/thread/j6zrdp1d148qpkg0g7x3cc41o070oq6n
> > Ralph>Virtually all of the contributors to the Log4j 1.x project left a
> few
> > years before it was declared
> > Ralph>EOL. That is the primary reason it was retired. Although the
> current
> > set of committers have
> > Ralph>access to the code, none of us have ever built it
> >
> > 2) Ralph Goers (a member of Logging PMC) suggested that one of the ways
> to
> > move forward is to re-incubate log4j 1.x:
> > https://lists.apache.org/thread/mlpb9v15r8qzpc58xnjn99r6tf9yy0p5
> >
> > This in conjunction with #1 sounds like the current logging PMC is not
> > interested in moving log4j 1.x forward.
> >
> > 3) I suggest moving log4j 1.x to Git, and nobody from PMC approves the
> > change;
> > Gary Gregory (a member of Logging PMC) votes with -1 (binding):
> > https://lists.apache.org/thread/y89v84okzs76g2yl760vx5yc0w1y4yd8
> >
> > 4) Both Gary and Mike push for "improving log4j 1->2 compatibility
> layer":
> > https://lists.apache.org/thread/hq2m11f1w9yp031r5f65b9h4ym2zy1kc
> > https://lists.apache.org/thread/tw172svxt1q6wds7lt9szyjw2sxjf34n
> >
> > I understand that log4j2 team might want everybody to upgrade to 2.x,
> > however, that is not possible since the apps would need significant
> > regression testing,
> > the compatibility layer is far from perfect, and so on.
> > Many apps are fine with 1.x, and they do not need 2.x features.
> > There's no reason to upgrade, so I am not interested in investing time in
> > improving
> > the compatibility layer.
> >
> > Is it what you ask?
> >
> > Vladimir
> >
>

Re: Looking for a champion: resurrect log4j 1.x

[John D. Ament]

Hi Vladimir,

I think based on what you're describing and the Logging PMC's response,
re-incubating the project makes sense.  I would be curious if the Logging
PMC would be interested in restarting the sub-project after a successful
incubation period.  This seems to match what Ralph is suggesting as well.

Typically this would mean that the VP Logging PMC would serve as the
champion, and as the sponsor the Logging PMC would still be the one to vote
to add the project to the incubator.  If the VP Logging isn't interested in
doing this, I would recommend starting out the project as a standalone
podling and keeping the Incubator as sponsor rather than Logging.  See [1]
for some details on those notes.  The incubator would be responsible for
voting on releases, receiving notices for new PPMC members, etc regardless
of who is the sponsor.  Given enough contributors and a diverse contributor
base then the Incubator PMC and the Logging PMC (if they're the sponsor)
would vote whether everyone feels the new project can be brought back to
the Logging project.  We can also decide as it gets closer to graduation to
move the podling into a sub-project if that's what everyone agrees.

I would be up for helping you get through the incubator.  If VP Logging
doesn't want to own the sponsorship part, I can be your Champion.

John


[1]: https://incubator.apache.org/guides/proposal.html#background

On Mon, Dec 20, 2021 at 8:20 AM Vladimir Sitnikov <
sitnikov.vladi...@gmail.com> wrote:

> >Do you have "facts" (like message on mailing list) ?
>
> I am not sure what you mean.
>
> For example:
>
> 1) Ralph Goers says the existing committers did not touch 1.x code a lot:
> https://lists.apache.org/thread/j6zrdp1d148qpkg0g7x3cc41o070oq6n
> Ralph>Virtually all of the contributors to the Log4j 1.x project left a few
> years before it was declared
> Ralph>EOL. That is the primary reason it was retired. Although the current
> set of committers have
> Ralph>access to the code, none of us have ever built it
>
> 2) Ralph Goers (a member of Logging PMC) suggested that one of the ways to
> move forward is to re-incubate log4j 1.x:
> https://lists.apache.org/thread/mlpb9v15r8qzpc58xnjn99r6tf9yy0p5
>
> This in conjunction with #1 sounds like the current logging PMC is not
> interested in moving log4j 1.x forward.
>
> 3) I suggest moving log4j 1.x to Git, and nobody from PMC approves the
> change;
> Gary Gregory (a member of Logging PMC) votes with -1 (binding):
> https://lists.apache.org/thread/y89v84okzs76g2yl760vx5yc0w1y4yd8
>
> 4) Both Gary and Mike push for "improving log4j 1->2 compatibility layer":
> https://lists.apache.org/thread/hq2m11f1w9yp031r5f65b9h4ym2zy1kc
> https://lists.apache.org/thread/tw172svxt1q6wds7lt9szyjw2sxjf34n
>
> I understand that log4j2 team might want everybody to upgrade to 2.x,
> however, that is not possible since the apps would need significant
> regression testing,
> the compatibility layer is far from perfect, and so on.
> Many apps are fine with 1.x, and they do not need 2.x features.
> There's no reason to upgrade, so I am not interested in investing time in
> improving
> the compatibility layer.
>
> Is it what you ask?
>
> Vladimir
>

Re: Looking for a champion: resurrect log4j 1.x

[Vladimir Sitnikov]

>Do you have "facts" (like message on mailing list) ?

I am not sure what you mean.

For example:

1) Ralph Goers says the existing committers did not touch 1.x code a lot:
https://lists.apache.org/thread/j6zrdp1d148qpkg0g7x3cc41o070oq6n
Ralph>Virtually all of the contributors to the Log4j 1.x project left a few
years before it was declared
Ralph>EOL. That is the primary reason it was retired. Although the current
set of committers have
Ralph>access to the code, none of us have ever built it

2) Ralph Goers (a member of Logging PMC) suggested that one of the ways to
move forward is to re-incubate log4j 1.x:
https://lists.apache.org/thread/mlpb9v15r8qzpc58xnjn99r6tf9yy0p5

This in conjunction with #1 sounds like the current logging PMC is not
interested in moving log4j 1.x forward.

3) I suggest moving log4j 1.x to Git, and nobody from PMC approves the
change;
Gary Gregory (a member of Logging PMC) votes with -1 (binding):
https://lists.apache.org/thread/y89v84okzs76g2yl760vx5yc0w1y4yd8

4) Both Gary and Mike push for "improving log4j 1->2 compatibility layer":
https://lists.apache.org/thread/hq2m11f1w9yp031r5f65b9h4ym2zy1kc
https://lists.apache.org/thread/tw172svxt1q6wds7lt9szyjw2sxjf34n

I understand that log4j2 team might want everybody to upgrade to 2.x,
however, that is not possible since the apps would need significant
regression testing,
the compatibility layer is far from perfect, and so on.
Many apps are fine with 1.x, and they do not need 2.x features.
There's no reason to upgrade, so I am not interested in investing time in
improving
the compatibility layer.

Is it what you ask?

Vladimir

Re: [VOTE] Release Apache YuniKorn (Incubating) 0.12.1 (RC1)

[sebb]

On Mon, 20 Dec 2021 at 04:29, Chaoran Yu  wrote:
>
> Hello IPMC,
>
> The Apache YuniKorn community has voted and approved the release of Apache 
> YuniKorn (incubating) 0.12.1 (RC1). We now kindly request IPMC members review 
> and vote for this release.
>
> YuniKorn is a standalone, universal resource scheduler that can support both 
> long-running and batch workloads. The current release offers enhancements and 
> improvements in a number of areas: node sorting performance, gang scheduling, 
> logging and observability, and scheduler interface. It also contains an 
> upgraded Kubernetes dependency (v1.20) and now supports running on Kubernetes 
> versions 1.19, 1.20 and 1.21.
>
> YuniKorn community vote thread: 
> https://lists.apache.org/thread/1yr4y7tftth5bfxlxfy4l8gmo3ypk4d2 
> 
>
> Vote result thread: 
> https://lists.apache.org/thread/z1f8wzx3t1n07qr8s4nfw224n74zryrs 
> 
>
> Issues included in this release: 
> https://issues.apache.org/jira/projects/YUNIKORN/versions/12350843 
> 
>
> The release candidate: 
> https://dist.apache.org/repos/dist/dev/incubator/yunikorn/0.12.1/ 
> 
>
> This release has been signed with a PGP available here: 
> https://dist.apache.org/repos/dist/dev/incubator/yunikorn/KEYS 
> 

-1

Please do NOT use the above URL for KEYS.

Only use

https://downloads.apache.org/incubator/yunikorn/KEYS

For the reasons why, please read recent emails to this list.
There have been several about the same issue.

> Git tag for the release:
> - https://github.com/apache/incubator-yunikorn-core/tree/v0.12.1 
> 
> - https://github.com/apache/incubator-yunikorn-k8shim/tree/v0.12.1 
> 
> - 
> https://github.com/apache/incubator-yunikorn-scheduler-interface/tree/v0.12.1 
> 
> - https://github.com/apache/incubator-yunikorn-web/tree/v0.12.1 
> 
>
> The vote will be open for at least 72 hours or until the necessary number of 
> votes is reached.
>
> Please vote accordingly:
> [ ] +1 Approve the release of Apache YuniKorn (Incubating) 0.12.1
> [ ] +0
> [ ] -1 Do not approve (please specify the reason)
>
> Thanks,
> Chaoran Yu
> Apache YuniKorn (Incubating)
>
>

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Looking for a champion: resurrect log4j 1.x

[Jean-Baptiste Onofré]

Hi Vladimir,

Thanks for the update. Do you have "facts" (like message on mailing list) ?
I think we can discuss with the log4j PMC members.
Depending of their feedback, we will find a way. My preference is to 
have log4j1 on Apache Logging umbrella.


Let's see what others think.

Regards
JB

On 20/12/2021 08:48, Vladimir Sitnikov wrote:

JB>Anyone can propose new releases on any branches (including old ones).
JB>If you need my support/help on this, please let me know.

I and the other contributors tried to suggest PRs, however, log4j pmc
actively denies them.
They suggest contributors should focus on polishing log4j 1->2
compatibility layer.
Making the compatibility 100% correct is hard, so I believe forcing
everybody to upgrade is not the right thing to do.

JB>Anyone can propose new releases on any branches (including old ones).

log4j pmc denies migrating from SVN to Git, so it is hard to even propose a
PR :( (see [4] in the first message)

JB>If you need my support/help on this

Did you mean "help with resurrecting" or "help with convincing log4j pmc
accepting PRs"? :)

Vladimir



-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org