On 15.12.2014 04:30, Ben Reser wrote:
> On 12/14/14 6:11 PM, Branko Čibej wrote:
>> As you've all seen, I voted against releasing 1.7.19 and 1.8.11, because
>> the DAV tests don't work with HTTPd 2.4+, which is the system default on
>> the latest version of OSX. I'd be surprised if OSX is the exception; it
>> seems to depend not just on the HTTPd version but also on the configured
>> I found that we've had the fix on trunk in davautocheck.sh for over a
>> year, and have proposed to backport it to 1.7.x and 1.8.x; it's a clean
>> I therefore propose that we scratch the 1.7.19 and 1.8.11 releases,
>> approve the backport and roll 1.7.20 and 1.8.12 with the fix included.
> I don't disagree we should fix this. But it's not a regression.
No, it isn't, which is why I wrote "vote against", not "veto". But it's
an easily-fixed nuisance. ISTR Julian mentioned he had similar
intermittent problems on Linux ... which might nor might not have the
> There are at least four possible workarounds.
> 1) Set the APACHE_MPM environment variable to something other than event.
> 2) Apply patches to the auto script (the backports you proposed).
> 3) Choose a different MPM at httpd build time.
> 4) Don't use davautocheck.sh and setup the httpd config yourself.
> The first of which is very low difficulty for anyone. It's something you need
> to do if for instance you have an event default MPM httpd and what to run
> mod_dav tests against BDB since we disallow event with BDB anyway.
Your fix in r1544303 is for prefork, which is the default on OSX 10.10.
If I can use neither event, nor prefork without the fix, there aren't
many options left. As for your point (3), I propose you use that
argument to all the people who're bound to complain about a broken
> davautocheck.sh is a convenience feature of the test suite at this point.
Ho hum ... if that's the case, we may as well say that the whole test
suite is a convenience feature and not worry about test failures during
I suspect a lot of downstream packagers tend to rely on 'make
davautocheck' to vet their packages, and HTTPd 2.4 is becoming more
widespread ... which is why I think it makes sense to fix this
"convenience" for our users, even if we know there are workarounds.
> sure it has numerous other failings in certain circumstances. 1.6.x wouldn't
> work on OS X either as I recall, yet nobody complained about it back then.
> Given that you've already located the correct fixes and nominated them, in my
> opinion we should just ship this release as is and then be sure to fix them for
> the next release.
> So my vote is not to delay this release.
I'm not going to try to stop the release, more than I've already done.
But I won't sign the tarballs; IMO, the release is broken, and given
that we've had a fix on trunk for more than a year, there's no reason
not to fix it. It's not as if we're in any particular hurry to roll
these releases right this minute.
Received on 2014-12-15 11:14:53 CET