apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Leggett <minf...@sharp.fm>
Subject Re: Time for apr-util-1.4.0?
Date Fri, 11 Feb 2011 01:40:54 GMT
On 10 Feb 2011, at 8:13 PM, William A. Rowe Jr. wrote:

> On 2/10/2011 8:27 AM, Jim Jagielski wrote:
>> What's holding us up for a release of apu-1.4.0?
> There have been calls for API review, nobody answered them.  I'd  
> vote -1
> at this point in time to ship unreviewed API additions and have  
> already
> pointed out function argument signature flaws that must be fixed.   
> (Turns
> out apr_dbd was used as the 'model', but apr_dbd itself was flawed in
> that respect from its introduction, and should be corrected at 2.0).
> Also the apr_crypto_device_ctx should never be passed, it should  
> become
> part of the apr_crypto_ctx structure itself.  Stack bytes are much  
> worse
> than heap bytes.

The work you describe above was completed and committed to apr-trunk  
over 12 months ago[1], and my key concern is that nobody has noticed  
that this took place.

I do realise that the key focus for many of the people who would be  
looking at APR[-util] has been httpd, with a desire to get httpd v2.4  
ready for beta, and I expect it explains why eyeballs haven't been  
looking at apr of late.

Right now, I have a big queue of work to be cleared that was stuck  
behind a whole lotta admin, but when that's cleared I can devote some  
time to backporting r899910  to apr-util v1.4. It would help immensely  
if people could look at the API on trunk and ensure that the issues  
that were raised are indeed solved.

[1] http://svn.apache.org/viewvc?view=revision&revision=899910

>  And I haven't seen clear feedback of original critics
> that their concerns were answered in the most recent refactorings.

People had time then, perhaps they don't have time to follow up now.  
The most important thing is that the people who do have time now  
understand the original concerns and are able to ascertain that the  
concerns have been addressed. This is why we have communities around  
code, to ensure that one person doesn't become a single point of  


View raw message