Passed: apache/httpd#930 (trunk - 6f6cc1d)

2020-07-01 Thread Travis CI
Build Update for apache/httpd
-

Build: #930
Status: Passed

Duration: 9 mins and 56 secs
Commit: 6f6cc1d (trunk)
Author: Yann Ylavic
Message: mpm_common: remove ap_mpm_unregister_poll_callback().

It's now called automatically by mpm_event and anyway can't be called safely
outside the MPM code without racing.

MAJOR bump.



git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1879422 
13f79535-47bb-0310-9956-ffa450edef68

View the changeset: 
https://github.com/apache/httpd/compare/9e1b133867d8...6f6cc1d2be69

View the full build log and details: 
https://travis-ci.org/github/apache/httpd/builds/704145112?utm_medium=notification_source=email


--

You can unsubscribe from build emails from the apache/httpd repository going to 
https://travis-ci.org/account/preferences/unsubscribe?repository=69847_medium=notification_source=email.
Or unsubscribe from *all* email updating your settings at 
https://travis-ci.org/account/preferences/unsubscribe?utm_medium=notification_source=email.
Or configure specific recipients for build notifications in your .travis.yml 
file. See https://docs.travis-ci.com/user/notifications.



Re: svn commit: r1879285 - in /httpd/httpd/trunk: CHANGES docs/manual/mod/core.xml include/ap_mmn.h include/http_core.h include/http_protocol.h include/httpd.h modules/dav/fs/repos.c modules/test/mod_

2020-07-01 Thread Jim Jagielski


> On Jun 29, 2020, at 10:27 AM, Graham Leggett  wrote:
> 
> On 29 Jun 2020, at 14:49, Yann Ylavic  > wrote:
> 
>>> Yes we can and should (but in separate commits).
>>> 
>>> I have my eye on the r->proxyreq flag, we can pack this into the binary 
>>> notes too, values don’t need to be one bit wide.
>> 
>> Actually I was thinking the other way around, have the new "unsigned
>> int strong_etag:1" bitfield rather than changing the existing ones...
>> Why adding complexity with bit(s) macros while bitfields exist?
> 
> The problem with bitfields in the public APIs is that they’re not binary 
> compatible across compilers. While it is very rare that a module will be 
> built with a different compiler than httpd was, it’s still theoretically 
> possible, and we should probably avoid it. Bitfields aren’t a problem for 
> in-module or in-core code.

++1