Re: svn commit: r169705 - in /httpd/httpd/trunk: include/util_ldap.h modules/ldap/util_ldap.c

[Paul Querna <ch...@force-elite.com>]

bnicholes@apache.org wrote:
> Author: bnicholes
> Date: Wed May 11 15:34:18 2005
> New Revision: 169705
> 
> URL: http://svn.apache.org/viewcvs?rev=169705&view=rev
> Log:
> Add the LDAPVerifyServerCert directive to util_ldap to force
> verification of a server certificate when establishing an SSL connection
> to the LDAP server
> 
> Modified:
>     httpd/httpd/trunk/include/util_ldap.h
>     httpd/httpd/trunk/modules/ldap/util_ldap.c
> 


Ack.  This commit means that httpd/trunk now depends on apr-util/trunk.
 Before this you were able to run httpd/trunk using APR-Util 1.1.x.

This effectively kills any httpd alphas until APR-Util 1.2.0 is released.

I believe we should uphold the policy of using only released versions of
a dependency.

I don't see an APR-Util 1.2.0 coming very soon. The APR-DBD code could
still use more love.

This is just an example of why I wanted to branch trunk to 2.1.x.  I
have nothing against adding this specific feature  -- it just happens to
require a non-released version of APR-Util.

Ideas for a solution that doesn't involve waiting for APR-Util 1.2.0?

Thanks,

-Paul

Re: Reverting vs branching, WAS: Re: svn commit: r169705 - in /httpd/httpd/trunk: include/util_ldap.h modules/ldap/util_ldap.c

[Garrett Rooney <ro...@electricjellyfish.net>]

Sander Striker wrote:

>> Ideas for a solution that doesn't involve waiting for APR-Util 1.2.0?
> 
> 
> Yes.  We could do the branch...

Heck, you don't even need to revert the commit to do that, just branch 
from the revision before the change was made to trunk...

-garrett

Reverting vs branching, WAS: Re: svn commit: r169705 - in /httpd/httpd/trunk: include/util_ldap.h modules/ldap/util_ldap.c

[Sander Striker <st...@apache.org>]

Paul Querna wrote:
> bnicholes@apache.org wrote:
> 
>>Author: bnicholes
>>Date: Wed May 11 15:34:18 2005
>>New Revision: 169705
>>
>>URL: http://svn.apache.org/viewcvs?rev=169705&view=rev
>>Log:
>>Add the LDAPVerifyServerCert directive to util_ldap to force
>>verification of a server certificate when establishing an SSL connection
>>to the LDAP server
>>
>>Modified:
>>    httpd/httpd/trunk/include/util_ldap.h
>>    httpd/httpd/trunk/modules/ldap/util_ldap.c
> 
> Ack.  This commit means that httpd/trunk now depends on apr-util/trunk.
>  Before this you were able to run httpd/trunk using APR-Util 1.1.x.

Which is a no-go.  Please revert.
 
> This effectively kills any httpd alphas until APR-Util 1.2.0 is released.
> 
> I believe we should uphold the policy of using only released versions of
> a dependency.

+1.

> I don't see an APR-Util 1.2.0 coming very soon. The APR-DBD code could
> still use more love.
> 
> This is just an example of why I wanted to branch trunk to 2.1.x.  I
> have nothing against adding this specific feature  -- it just happens to
> require a non-released version of APR-Util.
> 
> Ideas for a solution that doesn't involve waiting for APR-Util 1.2.0?

Yes.  We could do the branch...

Sander

Re: svn commit: r169705 - in /httpd/httpd/trunk: include/util_ldap.h modules/ldap/util_ldap.c

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

At 05:52 PM 5/11/2005, Paul Querna wrote:

>I believe we should uphold the policy of using only released versions of
>a dependency.

+1, however...

>I don't see an APR-Util 1.2.0 coming very soon. The APR-DBD code could
>still use more love.

Why not?  Looks like apr_dbd should simply be pushed off to
apr_util release 1.3.0 and get the other fixes and features
out the door, perhaps.

>This is just an example of why I wanted to branch trunk to 2.1.x.  I
>have nothing against adding this specific feature  -- it just happens to
>require a non-released version of APR-Util.

-1 for this specific purpose; I always saw httpd-2.2 as addressing
only the handful of things we never did quite finish in 2.0.  Those
being the auth reorg, auth ldap, proxy and cache.

If httpd-2.2 can really be boiled down to this small subset - I would
very much like to see this work adopted.  If it means creating a dbd-less
apr_util 1.2.0 then so be it. Thoughts?

Bill