The alternative is to polish the 1.x compatibility in 2.x which is both actively maintained and much easier to get releases published. Then users on 1.x can more easily upgrade to 2.x. I can almost guarantee that regardless of how many warnings we add to a potential 1.x release, we’ll get inundated with CVE reports, bug reports, and email, all related solely to 1.x which none of us wish to maintain (especially given most of us weren’t even involved in 1.x back when it was in development). -- Matt Sicker
> On Dec 19, 2021, at 16:48, Vladimir Sitnikov <sitnikov.vladi...@gmail.com> > wrote: > > Matt>but at least one release using the normal ASF release requirements is > required to graduate. > > Thanks for the reminder, and I am sure preparing the release won't be an > issue. I refactored release scripts for both Calcite and JMeter, and I am > sure log4j 1.x is doable. > >> compared to the alternatives discussed in this thread. > > I must be missing the alternarives. > Can you please highlight them? > > There were multiple suggestions and various PRs from external contributora, > yet the committers respond with vaugue messages. > > The code must be buildable, so moving to Git, and adding GitHub CI is the > mandatory step. > Of course, the existing PMC members and committers might have opinions on > the way to fix the issues, however I see no reasons for the team to deny > Git. > > The migration to Git consumes absolutely no resources from committers, > except a couple of +1 votes. > > Unfortunately, even a trivial improvement like Git is ignored by Logging > PMC. > > So I take Ralph's suggestion to reestablish the new PMC for log4j 1.x > seriously. > > Vladimir
