Improving legacy compatibility is what I've been pushing. I agree with Matt. IMO resurrecting 1.x sets a bad precedent and is a proverbial can of worms.
Gary On Sun, Dec 19, 2021, 17:55 Matt Sicker <boa...@gmail.com> wrote: > 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 > >
