apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bojan Smojver <bo...@rexursive.com>
Subject Re: Ready for 1.2.8 tags? (1.2.0 of apr-iconv)
Date Sat, 31 Mar 2007 01:37:41 GMT
Quoting "William A. Rowe, Jr." <wrowe@rowe-clan.net>:

>> - DBD drivers as DSOs backport (APR-util)
>> http://www.mail-archive.com/dev%40apr.apache.org/msg18012.html
> -1 - scope change, this seems it would violate versioning rules, or
> at least in the sense of stability.

AFAICT, this patch doesn't introduce any incompatibilities that would  
be on the list of no-nos for the bugfix release. The first part of it  
(the Python bit) was already committed to 1.2.x, by Joe. Not sure what  
you mean by sense of stability. Is it related to the .so files that  
end up in the installation location or something?

> Better for 1.3.0 / 2.0.0, and
> would rather ensure we've *solved* ALL the dynamic cases for dbd, dbm,
> ldap, expat and openssl instead of dealing with these piecemeal.

However, this partial solution in 1.2.x will help distributors  
eliminate some big depenedencies that currently exist and are not  
necessary (e.g. on Fedora, you need to install PostgreSQL in order to  
get apr-util installed).

> (Not suggesting the patch isn't the solution for all, if adapted,
> just that I'm not familiar enough with it yet, and it is very heavy
> weight for a minor bugfix release.)

OK. See above for one more try of convincing you to remove -1. I hope  
it worked :-)

>> - apr_file_gets()/apr_file_read() locking fix backport (APR)
>> http://www.mail-archive.com/dev%40apr.apache.org/msg18132.html
> Sounds good, citation of the actual commit to trunk?

It was not committed to the trunk yet. I let it simmer on the list,  
since it affects a pretty important function and I wasn't involved in  
writing the original. But, if everyone's OK with this, I'll commit.

>> PS. The locking patch is for Unix only. It would be good if folks that
>> do stuff for other platforms could have a look if there are similar
>> problems there.
> Speaking of which, if the apr_sdbm patch to *accept* buffered mode flag
> (not trigger it) would be dandy if not already backported.

Not too familiar with this one, as I wasn't involved. I'm sure folks  
that were patching this in SDBM will pick it up.


View raw message