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: Showstoppers to apr release(?)
Date Fri, 02 Nov 2007 17:22:56 GMT
Jeff Trawick wrote:
> On 10/15/07, William A. Rowe, Jr. <wrowe@rowe-clan.net> wrote:
>> Here's my list of open issues which should probably be determined before
>> we roll out 1.2.x, I was hoping we were further along than this on Unix
>> in particular;
> 
> Are you asking if these are regressions since the prior 1.2.x release
> (what I would call "showstopper"), or planning for these to be
> resolved before the next 1.2.x release whether or not they existed
> before (what I would call "nice to resolve, but not worth holding up
> the needed fixes")?

Well, the only thing holding me up is cleaning out every non-enhancement
bug that can be addressed reasonably.  Bugzilla says we've been mostly
successful.  I called out a short list of known things that I would see
fixed before I roll if anyone was actively solving them.  Otherwise I
plan to roll right over them.

> If the only showstoppers for the next release are
> 
> * regressions since 1.2.previous (that we developers know about, that
> are represented by bugzilla issues, or are exposed by test programs)
> * failure to correct apr's hand in application issues on Windows with
> 1.2.previous
> * maybe some other issue I don't know about

Darwin 9.  It's a clusterfuck, since we picked up on sendfile, and then
told them ever-so-nicely we can't compile sendrecv.c.  Joy :)

So - backport my patch from trunk which demonstrates either my bug or
darwin's bug?  Or disable sendfile detection for solaris?  Or actually
match ifdef-for-ifdef the mess in sendfile, and disable sendfile on
all unimplemented platforms?  /shrug - I'm growing beyond caring at this
point now that I recognize apple-folks couldn't be bothered to submit
any patches they had used.

> then I'm willing to invest considerable time in the 36 hours to check
> for *regressions* on some AIX 5.x level and HP-UX/PA-RISC 11iv1, and
> report and perhaps even fix what I can find.

While I was on the subject of Darwin, there's a lingering HPUX 11i issue
I wanted to address; HP's always claimed shl_load for 32-bit, but have
encouraged dlopen from the start for 64 bit.  I believe I have a reasonable
test for this in trunk, my last patch to configure.in.

You'll notice I shifted some platforms to avoid all the extra phooey of
testing for features we never use.  I left os390/400/aix alone.  I'm not
sure if you can move any of those up to the earlier "skip all the extras"
escape for their custom 'other' implementation?  I know aix will happily
use dlopen().

> With less certain criteria (end date), I'll continue to pitch in a few
> minutes here or there when practical.

End date was two weeks ago.  If someone is pursuing a must-have for 1.2.x
please holler about what you are fixing, otherwise I'm rolling by yesterday
already.  But if you will take on this configure.in review, I'd very much
like to solve shl/dl detection now for 1.2.

I don't plan to invest much more energy in 1.2 (I'd quit investing much
energy in 0.9 already).  So I'm not likely to RM again this year unless
something horrid comes up again, unless it's named 1.3.0 :-)

Bill

Mime
View raw message