vote + promote

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/branches/2.0.x@1469701 13f79535-47bb-0310-9956-ffa450edef68

diff --git a/STATUS b/STATUS
index 3058615eb21670a9b4e5417beb9bc23e351977a6..afaf4fc7beb37322fc7641e344ce262540afa514 100644 (file)
--- a/STATUS
+++ b/STATUS
@@ -190,36 +190,20 @@ RELEASE SHOWSTOPPERS:
 PATCHES ACCEPTED TO BACKPORT FROM TRUNK:
   [ start all new proposals below, under PATCHES PROPOSED. ]
 
-
-
-PATCHES PROPOSED TO BACKPORT FROM TRUNK:
-  [ please place SVN revisions from trunk here, so it is easy to
-    identify exactly what the proposed changes are!  Add all new
-    proposals to the end of this list. ]
-
-  * Backport 327179; PR 31226; allow ap_add_output_filters_by_type to handle
-    proxied requests.  Basic tests by jorton and [rpluem] show that this works,
-    nobody can actually remember why this limitation was introduced at all
-    (r94028) and the mailing list archives also gave no hint.
-      http://svn.apache.org/viewvc?view=rev&revision=327179
-    +0: covener, wrowe
-          do we need to make people opt-in for this behavior to
-          backport it to 2.0.x? What mechanism?
-
   * pcre: update config.guess and config.sub for better platform support.
     Trunk version of patch:
       Does not apply.
     Patch in 2.2.x branch:
       Does not apply.
     Use recent files from http://git.savannah.gnu.org/cgit/config.git.
-    +1: rjung, wrowe
+    +1: rjung, wrowe, humbedooh
 
   * mod_rewrite: PR 46428 - whitespace/encoding for proxied URL
     Trunk patch: http://svn.apache.org/viewvc?view=revision&revision=757427
     2.2.x patch: http://svn.apache.org/viewvc?view=revision&revision=773351
     Backport: http://people.apache.org/~rjung/patches/pr-46428-2_0.patch
     Revert r1002110 and r1002161 in test framework, once this is fixed.
-    +1: rjung, wrowe
+    +1: rjung, wrowe, humbedooh
 
   * mod_include: PR 39369 - timefmt config not working in SSI when using
     INCLUDES output filter and XBitHack On
@@ -227,7 +211,23 @@ PATCHES PROPOSED TO BACKPORT FROM TRUNK:
     2.2.x patch: http://svn.apache.org/viewvc?view=revision&revision=773352
     Backport: http://people.apache.org/~rjung/patches/pr-39369-2_0.patch
     Revert r1002174 in test framework, once this is fixed.
-    +1: rjung, wrowe
+    +1: rjung, wrowe, humbedooh
+
+
+PATCHES PROPOSED TO BACKPORT FROM TRUNK:
+  [ please place SVN revisions from trunk here, so it is easy to
+    identify exactly what the proposed changes are!  Add all new
+    proposals to the end of this list. ]
+
+  * Backport 327179; PR 31226; allow ap_add_output_filters_by_type to handle
+    proxied requests.  Basic tests by jorton and [rpluem] show that this works,
+    nobody can actually remember why this limitation was introduced at all
+    (r94028) and the mailing list archives also gave no hint.
+      http://svn.apache.org/viewvc?view=rev&revision=327179
+    +0: covener, wrowe
+          do we need to make people opt-in for this behavior to
+          backport it to 2.0.x? What mechanism?
+
 
   * byterange: Backport MaxRanges configuration directive and
     ap_set_accept_ranges() utility function.
@@ -249,7 +249,7 @@ PATCHES PROPOSED TO BACKPORT FROM TRUNK:
                  http://svn.apache.org/viewvc?view=revision&revision=103837
                  http://svn.apache.org/viewvc?view=revision&revision=966160
     Backport: http://people.apache.org/~rjung/patches/sslhonorcipher-2.0.patch
-    +1: rjung
+    +1: rjung, humbedooh
 
 PATCHES TO BACKPORT THAT ARE ON HOLD OR NOT GOING ANYWHERE SOON:
 
@@ -608,7 +608,7 @@ RELEASE NON-SHOWSTOPPERS BUT WOULD BE REAL NICE TO WRAP THESE UP:
       strong warnings!) will give authors a chance to vet their code.
 
     * There is increasing demand from module writers for an API
-      that will allow them to control the server à la apachectl.
+      that will allow them to control the server à la apachectl.
       Reasons include sole-function servers that need to die if
       an external dependency (e.g., a database) fails, et cetera.
       Perhaps something in the (ever more abused) scoreboard?