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

2022-11-18 Thread Marion & Christophe JAILLET

Hi Emmanuel,

just a nit: every commit triggers our CI (see [1]). This helps to spot 
new build issues and regression.


When a commit does not change the code itself, triggering the CI is not 
really useful and will likely only waste some CPU and bandwidth.
So when only STATUS, CHANGES or documentation are changed, you can add 
in the commit text the string "[skip ci]".


On the contrary, if for some reason a regression or build issue has been 
introduced, you can also touch these files (removing a trailing space, 
fixing a typo, ...) to force the CI to run.


If of interest to you, where to find CI reports is also explained in [1].


Happy hacking :)

CJ

[1]: https://httpd.apache.org/dev/devnotes.html#continuous-integration-ci



Le 19/11/2022 à 02:45, m...@apache.org a écrit :

Author: manu
Date: Sat Nov 19 01:45:24 2022
New Revision: 1905387

URL: http://svn.apache.org/viewvc?rev=1905387=rev
Log:
Backport ptoposal for DAVlockDiscovery option, and attempt to open DAVLockDB
read-only when possible.

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=1905387=1905386=1905387=diff
==
--- httpd/httpd/branches/2.4.x/STATUS (original)
+++ httpd/httpd/branches/2.4.x/STATUS Sat Nov 19 01:45:24 2022
@@ -282,6 +282,20 @@ PATCHES/ISSUES THAT ARE BEING WORKED
   make it nonblocking (by default)?
  jim: Non-blocking seems the best way to handle...
  
+  *) mod_dav: Open the lock database read-only when possible

+ trunk patch: http://svn.apache.org/r1905229
+ 2.4.x patch: trunk works
+ +1: manu
+
+  *) mod_dav: DAVlockDiscovery option to disable WebDAV lock discovery
+ This is a game changer for performances if client use PROPFIND a lot,
+ trunk patch: http://svn.apache.org/r1904638
+  http://svn.apache.org/r1904662
+  http://svn.apache.org/r1905170
+  http://svn.apache.org/r1905206
+  http://svn.apache.org/r1905230
+ 2.4.x patch: trunk works
+ +1: manu
  
  PATCHES/ISSUES THAT ARE STALLED
  





Re: svn commit: r1905170 - /httpd/httpd/trunk/modules/dav/main/mod_dav.c

2022-11-18 Thread Ruediger Pluem



On 11/17/22 6:41 PM, Emmanuel Dreyfus wrote:
> On Wed, Nov 16, 2022 at 08:05:43AM +0100, Ruediger Pluem wrote:
>> If you want to backport a patch to the 2.4.x branch just add your proposal 
>> to the STATUS file
> 
> This way?

Almost :-) Only a small nitpick. We don't backport the HTML changes to the 
documentation only the XML changes.
After the backport has happened you can either build the documentation again on 
the 2.4.x branch and commit there
(this is CTR) or you just do nothing as rebuilding the docs is part of the 
release procedure for 2.4.x.

Some people also put a svn command in the 2.4.x patch line like:

svn merge -c  1904638,1904662,1905170,1905206,1905230,1905327 
^/httpd/httpd/trunk .

Or they use a little bit different formatting. But these are all matters of 
taste and each of us has
a little different style there. You will notice this over time and find your 
own one.


> Index: STATUS
> ===
> --- STATUS  (revision 1905352)
> +++ STATUS  (working copy)
> @@ -282,7 +282,25 @@
>   make it nonblocking (by default)?
>  jim: Non-blocking seems the best way to handle...
>  
> +  *) mod_dav: Open the lock database read-only when possible
>  
> + trunk patch: http://svn.apache.org/r1905229
> + 2.4.x patch: trunk works
> + +1: manu
> +
> +  *) mod_dav: DAVlockDiscovery option to disable WebDAV lock discovery
> +
> + trunk patch: http://svn.apache.org/r1904638
> + trunk patch: http://svn.apache.org/r1904662 
> + trunk patch: http://svn.apache.org/r1905170
> + trunk patch: http://svn.apache.org/r1905206
> + trunk patch: http://svn.apache.org/r1905230
> + trunk patch: http://svn.apache.org/r1905327
> + 2.4.x patch: trunk works, except for 
> +  docs/manual/mod/mod_dav_fs.html.en.utf8 on trunk that is
> +  docs/manual/mod/mod_dav_fs.html.en on 2.4.x branch
> + +1: manu
> +
>  PATCHES/ISSUES THAT ARE STALLED
>  
>*) core: avoid duplicate headers when using ap_send_error_response.
> 

Regards

Rüdiger