Re: reset in proxy_balancer_method

2024-02-15 Thread jean-frederic clere
On 2/14/24 20:54, Ruediger Pluem wrote: 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:

Re: reset in proxy_balancer_method

2024-02-15 Thread Ruediger Pluem
On 2/15/24 9:28 AM, jean-frederic clere wrote: > On 2/14/24 20:54, Ruediger Pluem wrote: >> >> >> 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

Re: reset in proxy_balancer_method

2024-02-15 Thread jean-frederic clere
On 2/15/24 13:04, Ruediger Pluem wrote: On 2/15/24 9:28 AM, jean-frederic clere wrote: On 2/14/24 20:54, Ruediger Pluem wrote: 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

Re: age in proxy_balancer_method

2024-02-15 Thread jean-frederic clere
On 12/21/23 19:32, Rainer Jung wrote: I guess it could be like this: when Mladen originally implemented the by requests load balancing method in mod_jk he used the count and subtract method for the counters. He then ported this to mod_proxy_balancer and I think it is still, how by requests

Re: release apreq 2.18 and mothball the project

2024-02-15 Thread Yann Ylavic
On Thu, Feb 15, 2024 at 5:12 AM Joe Schaefer wrote: > > I gave you beta males an entire year His Alpha Most Serene Highness is too kind to us.. > to find an excuse for completely boning the modperl user community for no > good reason, _You_ did that (boning the modperl user community), by

Re: release apreq 2.18 and mothball the project

2024-02-15 Thread Joe Schaefer
You mean the 2.17 release, where Joe Orton actually patched the test suite out of your coercion? Great engineering. http://svn.apache.org/viewvc?view=revision=1903489 Joe Schaefer, Ph.D. Orion - The Enterprise Jamstack Wiki

Re: release apreq 2.18 and mothball the project

2024-02-15 Thread Eric Covener
On Wed, Feb 14, 2024 at 11:57 PM Joe Schaefer wrote: > Twenty years in core, with one bug to fix. > And you couldn’t even manage without three different botched releases. > I think you are mixing up apreq and httpd releases here. AIUI the apreq stuff in the core of httpd-trunk has only ever

Re: release apreq 2.18 and mothball the project

2024-02-15 Thread Frank Gingras
On Thu, Feb 15, 2024 at 5:47 PM Joe Schaefer wrote: > Nobody gives a flying f what you released from trunk. I personally will be > dead and buried before you release httpd 3.0. So like you I don’t give a > damned what you do with it. > > I just want the warfare against existing libapreq2 users

Re: release apreq 2.18 and mothball the project

2024-02-15 Thread Joe Schaefer
Let's be honest for once Yann. You came up with this hairbrained patch over 2 years ago right here: https://svn.apache.org/viewvc?view=revision=1895107 Yet the first time anyone actually ran the unit tests for apreq was during the 2.17 release process **8 months later**. And because you are

Re: release apreq 2.18 and mothball the project

2024-02-15 Thread Joe Schaefer
Nobody gives a flying f what you released from trunk. I personally will be dead and buried before you release httpd 3.0. So like you I don’t give a damned what you do with it. I just want the warfare against existing libapreq2 users to cease and desist. If there are known vulnerabilities in the

Re: release apreq 2.18 and mothball the project

2024-02-15 Thread Joe Schaefer
Keep your tone policing off list wise guy. If you have something of substance to offer to your colleagues other than defensive posturing, let’s have it. Like all these vacuous bug reports missing from the issue tracker about apreq, that you rumor mongers like to scare people with. Joe Schaefer,

Re: release apreq 2.18 and mothball the project

2024-02-15 Thread Joe Schaefer
The reason the QA around httpd is so lousy lately is because none of you actually dogfood the software professionally, because no Fortune 500 employer would be caught dead running httpd over nginx in the cloud. That historically lackadaisical approach to CI has no business persisting now that you

Re: release apreq 2.18 and mothball the project

2024-02-15 Thread Eric Covener
> And because you are such a prima donna Yann Yann is an amazing programmer and super easy to work with. Maybe it's hard to tell from the backseat.

Re: release apreq 2.18 and mothball the project

2024-02-15 Thread Joe Schaefer
Back in the day, httpd was a celebrated integration point for dozens of apache projects. Literally the flagship of the organization. It's also why people were judicious about what to include in core, versus codebases remaining elsewhere in the org as third party modules. Of course at this point,

Re: release apreq 2.18 and mothball the project

2024-02-15 Thread Joe Schaefer
The nightmare scenario is when you try to support HTTP/3 when you can’t even support an HTML form parser. Have an appropriate amount of fun. Popcorn is popping. Joe Schaefer, Ph.D. Orion - The Enterprise Jamstack Wiki

Re: release apreq 2.18 and mothball the project

2024-02-15 Thread Joe Schaefer
The proof is in the pudding, as it were. There's prima facia evidence in this very thread that he lied about ever running the test suite for apreq, because Joe wouldn't have had to patch it for him 8 months later had he ever bothered in the first place. But when everyone around you is no better

Re: release apreq 2.18 and mothball the project

2024-02-15 Thread Joe Schaefer
Stupid shit like this is everyone's problem: https://www.tenable.com/plugins/nessus/161454 Hating me for solving it cleanly is par for the course for the current httpd committer community. On Thu, Feb 15, 2024 at 8:41 PM Joe Schaefer wrote: > Back in the day, httpd was a celebrated

Re: release apreq 2.18 and mothball the project

2024-02-15 Thread Joe Schaefer
The mediocre talent pool in this community doesn’t mind the code duplication of having many different form data parsers inside a common code base because, really, collaboration and common cause is not your thing. So live it up with the user base while they ponder your architectural rationales