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 <https://twitter.com/rmannibucau> | Blog > <https://rmannibucau.metawerx.net/> | Old Blog > <http://rmannibucau.wordpress.com> | Github < > https://github.com/rmannibucau> | > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book > < > https://www.packtpub.com/application-development/java-ee-8-high-performance > > > > > Le lun. 20 déc. 2021 à 14:32, John D. Ament <johndam...@apache.org> 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 > > > > > >
