Re: release apreq 2.18 and mothball the project

Twenty years in core, with one bug to fix. And you couldn’t even manage without three different botched releases. Please, for the love of its users, stop fixing it. Joe Schaefer, Ph.D. Orion - The Enterprise Jamstack Wiki

Re: release apreq 2.18 and mothball the project

Look Eric, I gave you beta males an entire year to find an excuse for completely boning the modperl user community for no good reason, other than your precious egos were harmed while going though the motions for the past ten years with this project. So far, the only thing to come of putting

Re: release apreq 2.18 and mothball the project

Bite me Eric. Next? Joe Schaefer, Ph.D. Orion - The Enterprise Jamstack Wiki 954.253.3732 On Wed, Feb 14, 2024 at 10:25 PM Eric Covener wrote: > On Wed, Feb 14, 2024 at 1:45 PM Joe Schaefer wrote: > > > >

Re: release apreq 2.18 and mothball the project

On Wed, Feb 14, 2024 at 1:45 PM Joe Schaefer wrote: > > Assuming Google hasn't found any more fuzzing vulnerabilities with apreq, we > should call the subproject done after releasing it, rolling any new efforts > into httpd's internal copy of the codebase for the next major release of > httpd.

Re: reset in proxy_balancer_method

On 2/14/24 3:45 PM, jean-frederic clere wrote: > On 2/14/24 08:19, Ruediger Pluem wrote: >> >> >> On 2/9/24 11:59 AM, jean-frederic clere wrote: >>> Hi, >>> >>> I have noted to the reset() clean up too much in the balancers: >>> mod_lbmethod_bybusyness.c for example does: >>> +++ >>> for

release apreq 2.18 and mothball the project

Assuming Google hasn't found any more fuzzing vulnerabilities with apreq, we should call the subproject done after releasing it, rolling any new efforts into httpd's internal copy of the codebase for the next major release of httpd. Sound like a plan? I can get the ball rolling on the RM process

Re: reset in proxy_balancer_method

On 2/14/24 08:19, Ruediger Pluem wrote: On 2/9/24 11:59 AM, jean-frederic clere wrote: Hi, I have noted to the reset() clean up too much in the balancers: mod_lbmethod_bybusyness.c for example does: +++     for (i = 0; i < balancer->workers->nelts; i++, worker++) {    

Re: svn commit: r1915782 - in /httpd/httpd/branches/2.4.x: ./ build/PrintPath build/find_apr.m4 build/find_apu.m4 changes-entries/mod_slotmem_shm.txt modules/slotmem/mod_slotmem_shm.c

On 2/14/24 12:18, jfcl...@apache.org wrote: Removed: httpd/httpd/branches/2.4.x/build/PrintPath httpd/httpd/branches/2.4.x/build/find_apr.m4 httpd/httpd/branches/2.4.x/build/find_apu.m4 Oops I have undone that, sorry. -- Cheers Jean-Frederic

Re: using changes-entries or write in CHANGES directly

On Wed, Feb 14, 2024 at 11:28:15AM +0100, jean-frederic clere wrote: > So for 2.4.x on my accepted back port I have don't need changes-entries and > I have to process CHANGES by hands as I missed creating a changes-entries > file in trunk. If you file a Github PR for the backport you can still

Re: using changes-entries or write in CHANGES directly

On 2/14/24 11:06, Ruediger Pluem wrote: On 2/14/24 10:53 AM, jean-frederic clere wrote: Hi, Are there any rules to use changes-entries or write directly in CHANGES? IMHO change-entries is preferred. See http://svn.apache.org/viewvc/httpd/httpd/trunk/README.CHANGES?view=markup I just

Re: using changes-entries or write in CHANGES directly

On 2/14/24 10:53 AM, jean-frederic clere wrote: > Hi, > > Are there any rules to use changes-entries or write directly in CHANGES? > IMHO change-entries is preferred. See http://svn.apache.org/viewvc/httpd/httpd/trunk/README.CHANGES?view=markup I just noticed that we probably need a

Re: using changes-entries or write in CHANGES directly

> Am 14.02.2024 um 10:53 schrieb jean-frederic clere : > > Hi, > > Are there any rules to use changes-entries or write directly in CHANGES? Files in changes-entries make it easier to backport, as they will be no conflicts. > > -- > Cheers > > Jean-Frederic

using changes-entries or write in CHANGES directly

Hi, Are there any rules to use changes-entries or write directly in CHANGES? -- Cheers Jean-Frederic