Re: RFC: Documenting changes in the CHANGES file

2020-06-01 Thread Eric Covener
On Fri, May 29, 2020 at 3:30 PM Ruediger Pluem wrote: > > Reviewing our backport process I noticed that in many cases a clean merge via > svn merge fails due to conflicts in CHANGES. While > these are easy to solve it puts IMHO unnecessary extra work on the backport > process, both for

Re: RFC: Documenting changes in the CHANGES file

2020-06-01 Thread Graham Leggett
On 29 May 2020, at 21:30, Ruediger Pluem wrote: > Reviewing our backport process I noticed that in many cases a clean merge via > svn merge fails due to conflicts in CHANGES. While > these are easy to solve it puts IMHO unnecessary extra work on the backport > process, both for reviewing and

Re: RFC: Documenting changes in the CHANGES file

2020-06-01 Thread Jim Jagielski
Works for me. > On May 29, 2020, at 3:30 PM, Ruediger Pluem wrote: > > Reviewing our backport process I noticed that in many cases a clean merge via > svn merge fails due to conflicts in CHANGES. While > these are easy to solve it puts IMHO unnecessary extra work on the backport > process,

Re: Modern/simpler "proxy-send*" envs in trunk

2020-06-01 Thread Eric Covener
On Sat, May 30, 2020 at 8:14 AM Yann Ylavic wrote: > > How about we replace all the "proxy-send{cl,chunks,chunked}" logic in > mod_proxy_http (trunk only) with a single (inverse) > "proxy-no-chunked"? > > I think almost all backends nowadays support "chunked" > transfer-encoding, so the default

Re: RFC: Documenting changes in the CHANGES file

2020-06-01 Thread Yann Ylavic
On Fri, May 29, 2020 at 9:30 PM Ruediger Pluem wrote: > > Reviewing our backport process I noticed that in many cases a clean merge via > svn merge fails due to conflicts in CHANGES. While > these are easy to solve it puts IMHO unnecessary extra work on the backport > process, both for