I thought there was some old XML library that was resurrected here at Apache because other PMCs were still using it as a dependency. That might have been more so related to the Attic.
Anyways, as can be seen already, making non-controversial changes to 1.x that both the PMC and our users could accept could turn out to be fairly difficult, especially compared to the level of effort remaining in 2.x to ensure our 1.x backward compatibility support is further polished. I haven’t looked closely at 1.x (beyond some recent checks to see if the JNDI issue was exploitable there, too) in a few years, and even then it had a lot of technical debt to pay off simply related to the build environment and release process. It’s one thing to patch a class and throw a jar into the ever expanding repository that is Maven Central, but it’s a larger effort to publish an Apache release. Here are some resources about what’s required for a release along with some reference material that’s applicable for any Apache project: * https://www.apache.org/legal/release-policy.html <https://www.apache.org/legal/release-policy.html> * https://infra.apache.org/release-distribution.html <https://infra.apache.org/release-distribution.html> * https://infra.apache.org/release-publishing.html <https://infra.apache.org/release-publishing.html> * https://infra.apache.org/release-signing.html <https://infra.apache.org/release-signing.html> Note that the release requirements for ASF projects cannot be left out. There are less strict release requirements when going through the Incubator, but at least one release using the normal ASF release requirements is required to graduate. Please take these ASF requirements in mind when considering the amount of work remaining to be done to even get 1.x back into a releasable state compared to the alternatives discussed in this thread. -- Matt Sicker > On Dec 19, 2021, at 15:58, Gary Gregory <garydgreg...@gmail.com> wrote: > > WRT words, IIRC Apache only has top-level projects (for example, > Apache Logging Services, Apache Commons, Apache HttpComponents), > within that you can have components, not other projects, for example, > Apache Log4j, Apache Commons IO, Apache HttpComponents HttpCore. > > Gary > > On Sun, Dec 19, 2021 at 4:29 PM Ralph Goers <ralph.go...@dslextreme.com> > wrote: >> >> The Logging Services project is an “umbrella” project that manages all the >> logging projects, including Log4j 1.x. >> We would not be in favor of having Log4j 1.x become a new standalone PMC. >> >> But yes, any Logging Services PMC member can veto a code change in any of >> the sub-projects. >> I don’t know that it has ever happened. >> >> Ralph >> >>> On Dec 19, 2021, at 2:13 PM, Vladimir Sitnikov >>> <sitnikov.vladi...@gmail.com> wrote: >>> >>>> All new ASF projects go through the incubator. Sub-projects don’t have to >>> but when an entirely new community is being >>> >>> I'm a member of PMC Calcite and JMeter, however, I have not submitted >>> projects to the incubator yet. >>> >>>> Once graduated the podling >>> PMC members would become part of the Logging Services PMC. >>> >>> Does that mean the current members of Logging Services PMC could veto code >>> changes in the "new" log4j1? >>> That sounds strange, and it defeats the reason to re-establish the new set >>> of PMC members for log4j 1.x >>> >>> Vladimir >>
