Ruediger Pluem wrote:
On 11/20/2007 11:30 PM, William A. Rowe, Jr. wrote:
William A. Rowe, Jr. wrote:
Please provide your input to release.
[+1] APR-iconv-1.2.1
Please note I didn't see much feedback yet one way or another on
APR-iconv-1.2.1 nor
What can be done with APR-iconv, except
- checking md5 / signature
- compiling
- installing
yes, to all of the above. Also, the delta between 1.2.0 and 1.2.1 releases
is useful for inspection. Finally --with-iconv=/path/to/installed-apr-iconv
to apr-util should bind to this rather than to system iconv. Of course any
release vote is subject to your own metrics, with the general concensus that
non-regressions aren't showstoppers.
I see no test suite. Would the above results be enough for a qualified
vote. If yes, I can try to provide this (at least for some OS).
Once bound to apr-util, there is a simple apr-xlate validation test already,
in fact I'd rather we invested energy in validating apr_xlate than very
specific apr-iconv testing. (It's a win for apr-iconv, which might go away
sometime if citrus libs or icu become good solutions, and it remains a win
for checking against system iconv).
That test reveals one issue, not a regression, with a missing shift-out
of utf-7 encoding after a series of shifted bytes from the utf-8 source.
BTW: zip files would have been helpful for tests on windows as I missed
to install any of the usual suspect zip tools on the XP box I have
at hand :-(.
See /dev/dist now, however I didn't install testall, etc. I can see a good
rational for some install-tests target though, just to validate a binary
against a wider range of boxes.
Lucian's vote (not binding) and mine leave me looking for 2 more +1's to
wrap up this whole shooting match. Hard for me to shift apr-all-* binaries
without approval of apr-iconv-1.2.1 along with apr, apr-util 1.2.12.
Bill
