William A. Rowe, Jr. wrote:
> [EMAIL PROTECTED] wrote:
>> Author: pquerna
>> Date: Thu Oct 27 21:23:01 2005
>> New Revision: 329089
>>
>> URL: http://svn.apache.org/viewcvs?rev=329089&view=rev
>> Log:
>> Import apr_memcache trunk to APR-Util.
>>
>> Still TODO:
>> - Move CRC32 to a separate public function/API.
>> - Create a multi-get interface.
>> - Make locking and connection pooling optional.
> 
> For the moment, -1, please revert and begin an apr-memcache sandbox
> because...
> 
>  * it makes trunk/ unstable, preventing us from moving to 1.3

Then branch 1.3 and revert in the branch.  Trunk should always be safe
to commit to, IMHO.

>  * this seems entirely too specialized (in other words, useless code bloat)
>    All of the concepts here -are- useful, but not in this aggregation.

I disagree.  I think many others disagree.  We voted on this 4 days ago,
everyone who voted approved. It would of been helpful to see your
opinion then.  I understand we are all busy, but this feels like going
backwards in the discussion.  Its not bad, it just would of been nice to
raise these concerns in the vote thread.

>  * if we trust that this code is incomplete (my objections and your TODO)
>    then we have to partition it off for a while, till it's fleshed out.
>    With ABI/API stability a prime concern, dropping in an interface that
>    the group will suggest improvements and code style corrections for, is
>    a bad thing in a live 1.x release at this stage of it's development.

The code is complete. There is no API instability. It has been stable as
a separate project for nearly a full year.

My TODO that I mentioned in the commit log is to ADD features to the
API. The existing API would not be changed in any way.

-Paul

Reply via email to