On 31 May 2011, at 8:48 PM, William A. Rowe Jr. wrote:

> Of course it has been discussed, discussed, and discussed again, and  
> experienced
> a complete failure to launch.
>
> Rowe, Trawick, Erenkrantz and Orton voted to drop apr_ldap and give it
> over to httpd to maintain if they want it 12 1/2 months ago.  Whether
> httpd does or does not want it is really a topic for that dev list.
>
> http://mail-archives.apache.org/mod_mbox/apr-dev/201004.mbox/%3C4BD46614.6010503@rowe-clan.net%3E
> http://mail-archives.apache.org/mod_mbox/apr-dev/201005.mbox/%3CAANLkTinKzmDYbxo2VggZLOxPY72mH0OReK-kUeSGJSa3@mail.gmail.com%3E

I see a vote, and no on-list discussion that preceded it. Not only  
that, I see a vote on the dev@apr list proposing an as yet unheard of  
solution that concerns a completely separate project, with no  
discussion having happened on either project. This is not how a  
project at the ASF works.

> The interest in 'doing something someday' blocks APR v2.0 release,
> and blocking releases by inaction is always unacceptable at the ASF.
> It is the equivilant of leaving trunk in a not-compiling state (which
> I did only momentarily).

This issue does not block the APR v2.0 release, because this API is  
already in the APR v1.0 release and has been for many years. One  
person deciding they don't like a released API does not constitute  
grounds for a blocker of any kind.

> We now have something to review for apr_crypto, thanks to your  
> efforts,
> along with choice between libxml2 and expat, and my last project is to
> work out untangling apr 2.x from apr-iconv, which is one more  
> unmaintained
> code base to deprecate.

Leaving end users to discover that whole APIs have mysteriously  
disappeared without warning or explanation, without those APIs having  
been marked as deprecated, is grounds for a veto. So is the idea that  
another project will tolerate a code dump from one project to another,  
with the corresponding disruption to vendors that will result. In  
addition, APR has been a standalone library, depended on by many  
projects external to the ASF for many years, APR is not part of httpd,  
and code isn't interchangeable between them.

I have a proposal however to avoid the need for that, concerning the  
unfinished work combining apr and apr-util (something else performed  
without any notice or discussion on this list). I will follow up with  
another message.

> Nobody needs to stop anything on httpd v2.4, I am in the process of
> hooking up apr-2 correctly for that build for win32.  Quick review on
> unix indicates it works correctly.  But that would be a dev@httpd
> discussion.

Yeah, they do need to stop everything. Getting Roy's mod_cache  
blockers fixed on httpd before httpd's API is baked is more important  
than rewriting your API for you, and not only am I prepared to do one  
at a time, I am supposed to be having a holiday.

Regards,
Graham
--