apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: Status of showstopper in 0.9.x ?
Date Wed, 22 Feb 2006 16:52:42 GMT
Colm MacCarthaigh wrote:
> There's a showstopper listed in the apr STATUS file for 0.9.x;
> 
>    * MUST invert default selection of GPL, Sleepcat, BDB licensed plug
>      in detection to default to off, following clarification of the
>      ASF license compatibility
> 
>  a) Is this showstopper actually relevant to apr, or only apr-util? 
>     should it really be in apr-util's STATUS ?

Correct; it was apr-util

>  b) Is this still a valid showstopper, or did r376181 fix this for
>     the 0.9.x branch or not ? :)

Yes, point a) is moot, I believe this is committed to both branches, but
please verify both the gdbm and db patches were committed (seperately),
and this goes away.

> Just want to get a httpd candidate roll underway, and we need to clear
> the apr dependency first :)

All depends on if you would like the build fixes to uuid that have been
multiply reported on several unicies (particularly OS/X, but 37999 reflects
this problem on IRIX, and I've posted the exact solution last week, just no
time to hack the fix yet), the flush fixes and race fix specific to win32
and the flush fix to all implementations.  The OS/X one in particular means
I'm unable to generate 10.3 OS/X results, so I'll be -1'ing any release on
0.9.x branch at the moment for fundemental build failure.  <shrug>

I mean seriously, we devs *require* python 2.4 to ./buildconf now, I don't feel
like building it myself, so I end up fighting with a libuuid.dylib that just
'snuck in' with the python package without headers.  That is *not* a deployment
flaw, but a fact of life.

On the other hand, the crappy libiconv's gross hacks to subvert built-in clib
support for iconv() are a deployment flaw, and I don't think we aught to be
chasing our tails to undo gross namespace violations by another project.  So
what I thought I would need to deal with Solaris's build was better solved with
an rn iconv.h libiconv.h (badda bing badda boom.)

However, I'd have to -1 Solaris at the moment due to the inability to run
the tests to completion, because of the IPV6 hang in our linux-only test.
(If you don't believe me, see testsockets.c - we even documented it :-)
Once I can test on the two platforms, I'll be a whole lot further on voting
+0 to +1 for another release.

FWIW the Win32 flush and race fixes can be committed in the next 24 hours.
Unsure if I'll have time to do the public-locked-flush/internal-free-flush
fix across platforms in that same timeframe.

Anyone who cares to crawl the 28 open bugs in bugzilla will notice alot of very
low-hanging fruit.  It would be *REALLY* nice if some folks on the list helped
the couple of us finishing mopping that deck.  I don't mean 'please try latest
and report back' but commit the fixes that aught to be here.  I'd say about 12
of them offhand are worth an immediate fix to apr, some others 'would be nice',
and finally about another dozen are good suggestions for a 1.3.0 or 2.0 release.

I don't mean to 'get in the way' of moving forward, but it seems like only three
of the many developers here have applied any bug fixes in a while, and to get
folks to continue to push in bug fixes, we have to clear out the backlog once
in a while.  It's not like httpd, where there are long debates of 'does it work
or not?'  It seems like everyone says "well if nobody cares enough to fix the
win32 bugs let's keep moving" ... and yet when I really climb into the mud I'm
finding more issues on *nix-ish systems than win32 <grin />

Bill

Mime
View raw message