On Sat, May 29, 2021 at 11:55 AM Roy T. Fielding <field...@gbiv.com> wrote:
> On May 28, 2021, at 9:59 AM, William A Rowe Jr <wr...@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.
