I agree with Ralph here. Feel free to organize things to make a full release possible. If I can't build and run a release candidate from source, then I'll have trouble verifying and voting on a release down the line.
On Thu, Jan 6, 2022 at 1:21 PM Ralph Goers <[email protected]> wrote: > > Leo, > > Maybe, but maybe not. To be clear, the PMC still has concerns about this. But > Ceki has commit rights and obviously has quite a bit of knowledge on Log4j and > what was supported. > > My personal opinion is that the closer the build can get to producing a > release > that is 100% compatible with Log4j 1.2.17 the more receptive the PMC would > be to approve it. After all, the goal is to be a drop in replacement. > > Whatever happens I would not expect a release vote to be unanimous. More > than one PMC member simply believe that end-of-life means end-of-life. > > Ralph > > > On Jan 6, 2022, at 12:07 PM, Leo Simons <[email protected]> wrote: > > > > Hey Ceki, > > > > Builds and tests were already fixed up, see the most recent outstanding > > PRs. Might be faster to cherry-pick rather than to re-do; if you start to > > move things around you’ll have a hard time merging anything in. > > > > Cheers, > > > > Leo > > > > On Thu, 6 Jan 2022 at 19:39, Ceki Gülcü <[email protected]> wrote: > > > >> > >> Hello all, > >> > >> I have created the v1.2.8 branch under logging-log4j1.git [1]. I Will > >> proceed to move tests under the standard Maven location and have them > >> pass under surefire (without ant). > >> > >> This might take a while but should be feasible. > >> > >> [1] https://gitbox.apache.org/repos/asf/logging-log4j1.git > >> > >> > >> -- > >> Ceki Gülcü > >> > >> Please contact suppport(at)qos.ch for donations, sponsorship or support > >> contracts related to SLF4J or logback projects. > >> >
