You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Bill Stoddard <bi...@wstoddard.com> on 2003/01/13 19:35:38 UTC
APACHE_2_0_BRANCH and APR
There are two votes in the STATUS that deserve some on list discussion.
* APACHE_2_0_BRANCH uses a level of APR code branched from the
APACHE_2_0_43 tag.
yes: trawick, jerenkrantz
no: wrowe
wrowe observes that we have already finished substantial
bug fixing in 0.9.2-dev since APACHE_2_0_43, so branching
there seems arbitrary.
* APACHE_2_0_BRANCH uses a level of APR code versioned 0.9.2-dev
or later (to 0.9.9), so long it remains binary compatible.
yes: wrowe
no:
wrowe suggests that when apr chooses to break compatibility,
httpd would continue to use that last compatible build.
to the best of my knowledge, there is stuff in APR HEAD that breaks binary
compatability. Bill Rowe, how do you plan to reconcile tihs with your vote? In
principle, I agree that branching exactly at APACHE_2_0_43 might not be best
because it does not pick up good fixes, but your alternative does not address
the brokeness that exists now.
Bill
Re: APACHE_2_0_BRANCH and APR
Posted by "William A. Rowe, Jr." <wr...@apache.org>.
At 12:35 PM 1/13/2003, Bill Stoddard wrote:
>There are two votes in the STATUS that deserve some on list discussion.
>
> * APACHE_2_0_BRANCH uses a level of APR code branched from the
> APACHE_2_0_43 tag.
> yes: trawick, jerenkrantz
> no: wrowe
> wrowe observes that we have already finished substantial
> bug fixing in 0.9.2-dev since APACHE_2_0_43, so branching
> there seems arbitrary.
>
>
> * APACHE_2_0_BRANCH uses a level of APR code versioned 0.9.2-dev
> or later (to 0.9.9), so long it remains binary compatible.
> yes: wrowe
> no:
> wrowe suggests that when apr chooses to break compatibility,
> httpd would continue to use that last compatible build.
>
>to the best of my knowledge, there is stuff in APR HEAD that breaks binary
>compatability. Bill Rowe, how do you plan to reconcile tihs with your vote? In
>principle, I agree that branching exactly at APACHE_2_0_43 might not be best
>because it does not pick up good fixes, but your alternative does not address
>the brokeness that exists now.
I've just committed the fixes to correct the binary breakage, while maintaining
Justin's desire to use unsigned over signed quantities. I don't see those
as substantial breakage so we can move forward.
Those few applications that return > MAX_INT might appear as negatives to
applications that add too many elements, but I'm really not convinced that
you can even have more than MAX_INT queue or hash entries (or anywhere
near it) until you go to a 64P architecture with 64 bit pointers, 32 bit ints,
and those platforms are rare (Win64, and perhaps AIX or another one-off
unix.) Unixes are generally 64 ILP if I recall correctly.
In any case, this moves us forward and if the apr list wants to argue for
domain sizes of such indexes in APR 1.0, now is a good time to start
discussing the advantages/disadvantages.
Bill
Re: APACHE_2_0_BRANCH and APR
Posted by "William A. Rowe, Jr." <wr...@apache.org>.
At 12:35 PM 1/13/2003, Bill Stoddard wrote:
>There are two votes in the STATUS that deserve some on list discussion.
>
> * APACHE_2_0_BRANCH uses a level of APR code branched from the
> APACHE_2_0_43 tag.
> yes: trawick, jerenkrantz
> no: wrowe
> wrowe observes that we have already finished substantial
> bug fixing in 0.9.2-dev since APACHE_2_0_43, so branching
> there seems arbitrary.
>
>
> * APACHE_2_0_BRANCH uses a level of APR code versioned 0.9.2-dev
> or later (to 0.9.9), so long it remains binary compatible.
> yes: wrowe
> no:
> wrowe suggests that when apr chooses to break compatibility,
> httpd would continue to use that last compatible build.
>
>to the best of my knowledge, there is stuff in APR HEAD that breaks binary
>compatability. Bill Rowe, how do you plan to reconcile tihs with your vote? In
>principle, I agree that branching exactly at APACHE_2_0_43 might not be best
>because it does not pick up good fixes, but your alternative does not address
>the brokeness that exists now.
I've just committed the fixes to correct the binary breakage, while maintaining
Justin's desire to use unsigned over signed quantities. I don't see those
as substantial breakage so we can move forward.
Those few applications that return > MAX_INT might appear as negatives to
applications that add too many elements, but I'm really not convinced that
you can even have more than MAX_INT queue or hash entries (or anywhere
near it) until you go to a 64P architecture with 64 bit pointers, 32 bit ints,
and those platforms are rare (Win64, and perhaps AIX or another one-off
unix.) Unixes are generally 64 ILP if I recall correctly.
In any case, this moves us forward and if the apr list wants to argue for
domain sizes of such indexes in APR 1.0, now is a good time to start
discussing the advantages/disadvantages.
Bill