- *) mpm_queue: Put fdqueue code in common for MPMs event and worker.
- trunk patch: http://svn.apache.org/r1821624
- http://svn.apache.org/r1821625
- http://svn.apache.org/r1821626
- http://svn.apache.org/r1821627
- http://svn.apache.org/r1821629
- http://svn.apache.org/r1821632
- http://svn.apache.org/r1821635
- http://svn.apache.org/r1821639
- http://svn.apache.org/r1821644
- http://svn.apache.org/r1821647
- http://svn.apache.org/r1821648
- http://svn.apache.org/r1821649
- http://svn.apache.org/r1821650
- http://svn.apache.org/r1821651
- http://svn.apache.org/r1821659
- http://svn.apache.org/r1821660
- http://svn.apache.org/r1822366
- http://svn.apache.org/r1822367
- http://svn.apache.org/r1824381
- 2.4.x patch: svn merge ^/httpd/httpd/branches/2.4.x-mpm_fdqueue .
- (http://home.apache.org/~ylavic/patches/httpd-2.4.x-mpm_fdqueue.patch)
- +1: ylavic, minfrin
- ylavic: The branch merge helps resolve move conflicts since event and
- worker fdqueue.[ch] differ(ed) between 2.4.x and trunk. The patch
- is provided only to help review.
- ylavic: re MMN, the API is private, so no bump (supposedly).
- minfrin: Keeping mpm_fdqueue.h private makes it hard for people to fork event
- and worker and make their own mpms. Can we make this public?
- ylavic: not easier/harder than now I suppose (worker/event fqueues are private).
- maybe make them public in trunk only, so that we have more time to
- discuss the API (if needed).
- minfrin: happy with that, we can backport the final API.
-
- *) mpm_event: Do lingering close in worker(s).
- trunk patch: http://svn.apache.org/r1823047
- http://svn.apache.org/r1824454
- http://svn.apache.org/r1824463
- http://svn.apache.org/r1824464
- http://svn.apache.org/r1824497
- 2.4.x patch: http://home.apache.org/~ylavic/patches/httpd-2.4.x-event-lingering_close_in_worker.patch
- (trunk works if mpm_queue above is merged first, otherwise
- the mpm_queue branch can also be synchronized after this
- merge, YMMV :)
- +1: ylavic,
-
- *) mod_ssl: Introduce SSLPolicy/SSLPolicyDefine directives.
- trunk patch: http://svn.apache.org/r1805182
- http://svn.apache.org/r1805186
- http://svn.apache.org/r1808335
- http://svn.apache.org/r1811475
- http://svn.apache.org/r1817381
- http://svn.apache.org/r1817894
- 2.4.x patch: https://svn.apache.org/repos/asf/httpd/httpd/patches/2.4.x/mod_ssl_policy.diff
- +1: icing, minfrin
- minfrin: 2.4.x patch not applying for me, trunk patches work
- icing: fixed the patch to include complete new files instead of svn's internal optimizations
+ *) mod_dav: Allow other modules to become providers and add ACLs
+ to the DAV response.
+ trunk patch: http://svn.apache.org/r1748322
+ http://svn.apache.org/r1824590
+ http://svn.apache.org/r1824596
+ 2.4.x: trunk works modulo CHANGES/MMN/log-message
+ +1: minfrin, jim
+ -1: rpluem: While we allow extensions of structures at the end in general
+ this is a specific case where the the design of the mod_dav
+ API clashes with this approach, as the API requires consumers
+ to create the public structs on their own, something we do
+ not "allow/encourage" otherwise in order to be able to do the
+ structure extension. I don't want to see consumers of this API
+ suffer from the clash we created.
+ See also:
+ https://lists.apache.org/thread.html/b924afe0fcc58a8636b753e630421bf6dc2080653a79575fd5fd641a@%3Cdev.httpd.apache.org%3E