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 <johndam...@apache.org> 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 <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 > > > > > > > > > >
