Nobody in the Logging PMC is blocking a release here. What we don’t want is to falsely advertise that v1 is still under development. We already have a huge increase in mailing list, PR, and other traffic ever since Log4Shell, and if we resurrect v1, then it’ll quickly become impossible to keep up with all the activity given the size of the PMC. If any non-trivial work is to be done in v1, we’d prefer to see more than one person working on that, especially if we want to add more PMC members to oversee v1 in the first place.
And as for the v1 :: COBOL analogy, that’s not a bad comparison. Basically, users who haven’t bothered to upgrade in 10 years will have to end up paying astronomical costs for consultants who can still work on ancient software effectively to help modify their systems. Was Maven even widely used back when v1 was popular? Or were people still using a mix of make or Ant? -- Matt Sicker > On Dec 21, 2021, at 07:13, Romain Manni-Bucau <rmannibu...@gmail.com> wrote: > > Le mar. 21 déc. 2021 à 12:33, Enrico Olivelli <eolive...@gmail.com> a > écrit : > >> Vladimir, >> I totally support this proposal. >> >> Which are actually the steps we need to cut a release of log4j 1.x ? >> - establish an Apache project ? >> > > 1. Send a patch to apply on > http://svn.apache.org/repos/asf/logging/log4j/trunk > > >> - do the fix >> > > 2. Get it applied > > >> - cut a release >> >> Can this be done inside another Apache Project who "adopts" the log4j >> sources if the Logging Project doesn't want to do it ? >> > > The PMC of log4j2 is logging project so it should be done there, if not the > project can be forked inside Apache but should change of package until we > get the perms to reuse the same one which means likely as much work as just > getting it done at logging project so hope it is not needed ;). > > >> >> Enrico >> >> >> Il giorno mar 21 dic 2021 alle ore 08:36 Vladimir Sitnikov < >> sitnikov.vladi...@gmail.com> ha scritto: >> >>>> 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 >>> >> --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
