You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@httpd.apache.org by yl...@apache.org on 2016/08/16 22:29:56 UTC

svn commit: r1756556 - /httpd/httpd/branches/2.4.x/STATUS

Author: ylavic
Date: Tue Aug 16 22:29:56 2016
New Revision: 1756556

URL: http://svn.apache.org/viewvc?rev=1756556&view=rev
Log:
Vote, promote.

Modified:
    httpd/httpd/branches/2.4.x/STATUS

Modified: httpd/httpd/branches/2.4.x/STATUS
URL: http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/STATUS?rev=1756556&r1=1756555&r2=1756556&view=diff
==============================================================================
--- httpd/httpd/branches/2.4.x/STATUS (original)
+++ httpd/httpd/branches/2.4.x/STATUS Tue Aug 16 22:29:56 2016
@@ -124,6 +124,35 @@ RELEASE SHOWSTOPPERS:
 PATCHES ACCEPTED TO BACKPORT FROM TRUNK:
   [ start all new proposals below, under PATCHES PROPOSED. ]
 
+  *) mod_dav: Add support for childtags to dav_error.
+     trunk patch: http://svn.apache.org/r1746207
+     2.4.x: trunk works modulo CHANGES/MMN
+     +1: minfrin, jim, ylavic
+
+  *) mod_dav: Add dav_begin_multistatus, dav_send_one_response,
+     dav_finish_multistatus, dav_send_multistatus, dav_handle_err, 
+     dav_failed_proppatch, dav_success_proppatch to mod_dav.h.
+     trunk patch: http://svn.apache.org/r1748047
+     2.4.x: trunk works modulo CHANGES/MMN
+     +1: minfrin, jim, ylavic
+
+  *) mod_proxy: Correctly consider error response codes by the backend when
+     processing failonstatus. PR 59869
+      Trunk version of patch:
+         http://svn.apache.org/r1753592
+      Backport version for 2.4.x of patch:
+         Trunk version of patch works (modulo CHANGES)
+      +1: rpluem, jim, ylavic
+
+  *) mod_proxy_balancer: Prevent redirect loops between workers within a
+     balancer by limiting the number of redirects to the number balancer
+     members. PR 59864
+      Trunk version of patch:
+         http://svn.apache.org/r1753594
+      Backport version for 2.4.x of patch:
+         Trunk version of patch works (modulo CHANGES)
+      +1: rpluem, jim, ylavic
+
 
 PATCHES PROPOSED TO BACKPORT FROM TRUNK:
   [ New proposals should be added at the end of the list ]
@@ -135,18 +164,6 @@ PATCHES PROPOSED TO BACKPORT FROM TRUNK:
      +1: trawick
      ylavic: there may be missing bits, see thread for commit r1736510.
 
-  *) mod_dav: Add support for childtags to dav_error.
-     trunk patch: http://svn.apache.org/r1746207
-     2.4.x: trunk works modulo CHANGES/MMN
-     +1: minfrin, jim
-
-  *) mod_dav: Add dav_begin_multistatus, dav_send_one_response,
-     dav_finish_multistatus, dav_send_multistatus, dav_handle_err, 
-     dav_failed_proppatch, dav_success_proppatch to mod_dav.h.
-     trunk patch: http://svn.apache.org/r1748047
-     2.4.x: trunk works modulo CHANGES/MMN
-     +1: minfrin, jim
-
   *) core: Drop an invalid Last-Modified header value coming
      from a FCGI/CGI script instead of replacing it with Unix epoch.
      Warn the users about Last-Modified header value replacements and
@@ -187,42 +204,26 @@ PATCHES PROPOSED TO BACKPORT FROM TRUNK:
      not been modified (HTTP 304) to avoid subsequent bogus reads and
      confusing error messages logged.
      trunk patch: http://svn.apache.org/r1752347
-     2.4.x patch: trunk works
-     +1 elukey
+     2.4.x patch: trunk works (modulo CHANGES)
+     +1: elukey, ylavic
 
   *) autoconf: minor cleanup and removal of some dead code.
      trunk patch: http://svn.apache.org/r1753315
                   http://svn.apache.org/r1753316
      +1: jchampion
+     ylavic: some conflicts with r1753315 in 2.4.x's configure.in.
 
   *) mod_proxy_fcgi: avoid loops serving proxied error documents.
      trunk patch: http://svn.apache.org/r1753167
-     2.4.x patch: trunk works
-     +1: elukey
-
-  *) mod_proxy: Correctly consider error response codes by the backend when
-     processing failonstatus. PR 59869
-      Trunk version of patch:
-         http://svn.apache.org/r1753592
-      Backport version for 2.4.x of patch:
-         Trunk version of patch works (modulo CHANGES)
-      +1: rpluem, jim
-
-  *) mod_proxy_balancer: Prevent redirect loops between workers within a
-     balancer by limiting the number of redirects to the number balancer
-     members. PR 59864
-      Trunk version of patch:
-         http://svn.apache.org/r1753594
-      Backport version for 2.4.x of patch:
-         Trunk version of patch works (modulo CHANGES)
-      +1: rpluem, jim
+     2.4.x patch: trunk works (modulo CHANGES)
+     +1: elukey, ylavic
 
   *) mod_http: Add the HEAD method to the lookup hash for completeness.
       Trunk version of patch:
          http://svn.apache.org/r1753257
       Backport version for 2.4.x of patch:
          Trunk version of patch works
-      +1: wrowe
+      +1: wrowe, ylavic
 
   *) Typo fixes in comments and text files. PR 59990.
       Trunk version of patch:
@@ -231,7 +232,7 @@ PATCHES PROPOSED TO BACKPORT FROM TRUNK:
          http://home.apache.org/~rjung/patches/httpd-2.4.x-typo-PR59990.patch
          (trunk version of patch merge plus CHANGES plus STATUS
           plus one hunk in modules/aaa/mod_auth_digest.c)
-      +1: rjung
+      +1: rjung, ylavic
 
   *) mod_ssl: Fix quick renegotiation (OptRenegotiaton) with no intermediate
      in the client certificate chain.  PR 55786.

Re: svn commit: r1756556 - /httpd/httpd/branches/2.4.x/STATUS

Posted by Jacob Champion <ch...@gmail.com>.
On 08/18/2016 04:11 AM, Yann Ylavic wrote:
> On Wed, Aug 17, 2016 at 7:08 PM, Jacob Champion <ch...@gmail.com> wrote:
>>
>> What's the procedure for dealing with this in STATUS when I propose
>> something? A 2.4.x patch hosted... somewhere?
>
> Yes, you can propose a branch merge in a standalone patch, and give a
> link to it in a "2.4.x patch: ..." line (otherwise, this line is
> usually "trunk works [modulo CHANGES/MMN --which the "merger" can
> easily resolve itself]".
>
> That way, the votes refer to the proposed patch, finally simply
> applied on the branch (with --record-only for the mergeinfo of trunk
> commits).

Ah, didn't know about --record-only; that explains other things for me. 
Thanks!

> For hosting the patches, it's either an external address (lifetime of
> the vote, at least ;) or your own Apache space at
> home.apache.org/~yourid/ (you may want to configure your SSH
> authorized_keys line on id.apache.org to be able to access it via
> sftp).

Thanks (and thanks to R�diger too!). The 2.4.x patch is up and reflected 
in STATUS now.

>> Or do we just rely on proper
>> manual resolution by whoever merges the patches?
>
> Ouch, no one would want to merge :)

Well, I guess if the merges are gigantic and the conflicts are nasty, sure.

> Also, votes wouldn't always correspond to the result...

Makes sense.

--Jacob

Re: svn commit: r1756556 - /httpd/httpd/branches/2.4.x/STATUS

Posted by Yann Ylavic <yl...@gmail.com>.
On Wed, Aug 17, 2016 at 7:08 PM, Jacob Champion <ch...@gmail.com> wrote:
>
> What's the procedure for dealing with this in STATUS when I propose
> something? A 2.4.x patch hosted... somewhere?

Yes, you can propose a branch merge in a standalone patch, and give a
link to it in a "2.4.x patch: ..." line (otherwise, this line is
usually "trunk works [modulo CHANGES/MMN --which the "merger" can
easily resolve itself]".

That way, the votes refer to the proposed patch, finally simply
applied on the branch (with --record-only for the mergeinfo of trunk
commits).

For hosting the patches, it's either an external address (lifetime of
the vote, at least ;) or your own Apache space at
home.apache.org/~yourid/ (you may want to configure your SSH
authorized_keys line on id.apache.org to be able to access it via
sftp).


> Or do we just rely on proper
> manual resolution by whoever merges the patches?

Ouch, no one would want to merge :)
Also, votes wouldn't always correspond to the result...


Regards,
Yann.

RE: svn commit: r1756556 - /httpd/httpd/branches/2.4.x/STATUS

Posted by Plüm, Rüdiger, Vodafone Group <ru...@vodafone.com>.

> -----Original Message-----
> From: Jacob Champion [mailto:champion.p@gmail.com]
> Sent: Mittwoch, 17. August 2016 19:09
> To: dev@httpd.apache.org
> Subject: Re: svn commit: r1756556 - /httpd/httpd/branches/2.4.x/STATUS
> 
> On 08/16/2016 03:29 PM, ylavic@apache.org wrote:
> >    *) autoconf: minor cleanup and removal of some dead code.
> >       trunk patch: http://svn.apache.org/r1753315
> >                    http://svn.apache.org/r1753316
> >       +1: jchampion
> > +     ylavic: some conflicts with r1753315 in 2.4.x's configure.in.
> 
> Trunk has config files that aren't present in 2.4.x, so the massive list
> of "files to generate" conflicts.
> 
> What's the procedure for dealing with this in STATUS when I propose
> something? A 2.4.x patch hosted... somewhere? Or do we just rely on
> proper manual resolution by whoever merges the patches?

In most cases people store the 2.x backport patch version (that resolves merge conflicts)
in their personal space on home.apache.org. (see line 250 in the current version of STATUS
as an example. Keep n mind that home.apache.org replaced people.apache.org).

Regards

Rüdiger

Re: svn commit: r1756556 - /httpd/httpd/branches/2.4.x/STATUS

Posted by Jacob Champion <ch...@gmail.com>.
On 08/16/2016 03:29 PM, ylavic@apache.org wrote:
>    *) autoconf: minor cleanup and removal of some dead code.
>       trunk patch: http://svn.apache.org/r1753315
>                    http://svn.apache.org/r1753316
>       +1: jchampion
> +     ylavic: some conflicts with r1753315 in 2.4.x's configure.in.

Trunk has config files that aren't present in 2.4.x, so the massive list 
of "files to generate" conflicts.

What's the procedure for dealing with this in STATUS when I propose 
something? A 2.4.x patch hosted... somewhere? Or do we just rely on 
proper manual resolution by whoever merges the patches?

--Jacob