On Sat, May 29, 2021 at 11:55 AM Roy T. Fielding <fielding@gbiv.com> wrote:
On May 28, 2021, at 9:59 AM, William A Rowe Jr <wrowe@rowe-clan.net> wrote:

AIUI, as he remains a PMC member, the veto remains binding per Roy's conclusion, whether it was made 9 weeks ago or 9 years ago. I do not, so just sharing historical pointers for those raising questions, no opinion remaining of HTTP Server PMC choices at all. But I did want to point out that the project did choose to ignore the vastly more secure PCRE 10 rewrite and is still stuck at PCRE 8 (although I run bleed builds all the time of httpd trunk X apr 2 trunk X pcre 10 with no issues at all.) In theory, if the APR project has enough maintainers (minimum 3, more + than - votes), then apr[+util] 1.x might persist for years after a 2.0 release, if such a release occurs.

The veto, like any veto, was specific to both the context at the time (2.4.0)
and the change being made. The way to resolve it is to work together
towards either a common solution (in APR) or a narrow change (in httpd).

I think everyone shares this sentiment, although your timeline is just a bit off,
this was at 2.3 alpha as we were approaching beta, as the same time as the
APR project was looking forward at a version major release that hasn't
occurred since then.

The way to not get anything done in ten years is to claim that someone
doesn't have the right to veto a change, and then insist on having the
high ground instead of working toward anything.

You might be confused, I acknowledged the veto 10 years ago, the only
thing that hasn't happened in 10 years is that the API within the APR project
didn't lose its dependency on another project's header files, and the veto
lives on at httpd to adopt the code the APR crew collectively and nearly
unanimously threw off the boat as incomplete for a 2.0 release. I never
rejected anyone's efforts to advance the exact API at httpd, and never
rejected any effort anyone would bring to APR to isolate the dependency
chain to APR's headers alone. But you know more than anyone that what
is decided for APR is decided by APR, and this is the wrong list to discuss
that side of the equation. The many of us looked to your guidance through
this discussion Roy, and I accepted whatever you concluded, at both of the
projects, as I think most other participants did.
 
Projects don't *do* things; people do, preferably while working together
within the same project. It is much harder for people to do things together
when individuals are being painted into a corner, having their concerns
disregarded, or repeatedly being attacked just because you don't agree
with one decision they made.

You. I'm taking that personally, but it's irrelevant, I'm not a PMC member
here at httpd, and I haven't been in the way of any committee business
for nearly 2 years. I jumped off the administration of this teetering barge 
a while ago to let other headstrong people pilot it and give my head and
heart a break from the inanity.
 
I suggest that the way to fix this tiny little problem is to create a new
LDAP secure client library in httpd that has the very specific purpose
we need (call it ap_ldapsc_*) and then change httpd's current usage to
make use of that library instead. If that leads to enough energy to
eventually become a common utility on its own, then it can migrate
to a common LDAP library (not necessarily APR) at that later time.

That sounds great, I'm sure the httpd community can get behind any
workable solution (and perhaps, it doesn't have to be that complex,
sounds like a workable APR solution even.) In any case, a veto by the 
author themself of their own code is a most strange thing that's ever 
happened at the ASF. 

Likewise, the way to update to PCRE 10 is to do the work necessary for
the update, including backwards compatible shims. It would make for
a good entry/student project.

Indeed, since I also did that work almost a decade ago, it's waiting for 
a trivial change to configure.in - and a possible optimization since stack
is off the table due to the recursive complexity of regex expansion, and 
we never quite settled on our thread local storage best practice.

Also, to Stefan, yes I recognized your coding pattern as making it very
simple to drop in a less complex client implementation than libcurl. It's
just so odd that we have a client all baked out in httpd, it's called 
mod_proxy_http, but basically it can't be repurposed. Pretty strange,
I'm glad a few committers tried to tackle serf in the first place based
on that gap and subversion's needs.

I look forward to seeing what/how the httpd community collectively 
decides to move forward, I'm liking the dialog on how to catalog the
changes history.