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 >> MPM. >> >> 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 >> merge. >> >> 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 same cause. > 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. :) > 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 release testing. 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. > I'm > 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. -- Brane
