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/%[email protected]%3E
http://mail-archives.apache.org/mod_mbox/apr-dev/201005.mbox/%[email protected]%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
--
