On Aug 20, 2007, at 4:36 PM, William A. Rowe, Jr. wrote:
Jim Jagielski wrote:
Status Update:
There are issues in the current shipping version of
APR 0.9 that must be resolved before we can reroll 2.0.x.
Furthermore, there are issues in APR 1.2 that should be
fixed (although not regression related) before we redo
2.2.x... Once APR is tagged and rolled, we will use
that to T&R 2.0.x and 2.2.x.
If APR takes too much longer I may reconsider going
ahead and releasing the 2.2.5 tarball anyway,
since I don't want to delay 1.3/2.2 much further.
We *need* to wait for 0.9 for 2.0 because of
the regression...
It turns out that in 2.2, we have a regression 8 mos old.
Unfortunately
we didn't pick up on it, because piped logs aren't something that the
perl-framework understands.
The crux of the problem is that we create processes without a full
host
of three fd's. Then we inflict them against sh. Linux/bash
doesn't seem
to mind, but solaris sh, and I'm guessing aix and hpux stock /bin/
sh are
not going to like this situation either. Obviously win32 minded,
but this
is an artifact of how we assembled things.
We need three fd's to each logger process, but it's not as simple
as that.
We've collectively tacked on so much bubblegum and bailing wire
trying to
make the piped logger behave that it's missing any sensibility :) I'm
trying to restore that back to a working state.
I'd be +1 to releasing 2.2.6 today if we simply wanted to back out the
entire pile of cruft added since we started invoking /bin/sh to launch
log pipes. Till it behaves sensibly, I'll be -1 on release.
Of course, releases can't be vetoed, but doing further research
indicates that Bill looks to be spot on with this issue...
