Re: RFC: Documenting changes in the CHANGES file
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 reviewing and for actually doing the > backport. How about if we change the way we document changes the following > way: > > 1. We create a changes-fragments directory (name to be determined) at the top > level. > 2. For each release we create a subdirectory such that we end up with the > following structure: > >changes-fragments/ > 2.4.41/ > 2.4.42/ > 2.4.43/ > 2.4.44/ > > 3. Each directory contains the changes for each release and each change entry > is a single file. > 4. We have a script that builds our current CHANGES file from the content in > changes-fragments directories with the help of >a template or at least some sort of header / footer that is static. > 5. This script can be called either manually and we commit the resulting > CHANGES file as we like just like the x-forms commits >for documentation plus this script is called by the release scripts from > Daniel as part of the preparation of rolling a >release. If we removed or generalized the banner at the top of each changes, and added extra whitespace between entries, would svn merge push stuff to the top any better? I don't know if it would hunt for more non-whitespace context to try to figure out how to merge.
Re: RFC: Documenting changes in the CHANGES file
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 for actually doing the > backport. How about if we change the way we document changes the following > way: > > 1. We create a changes-fragments directory (name to be determined) at the top > level. > 2. For each release we create a subdirectory such that we end up with the > following structure: > > changes-fragments/ > 2.4.41/ > 2.4.42/ > 2.4.43/ > 2.4.44/ > > 3. Each directory contains the changes for each release and each change entry > is a single file. > 4. We have a script that builds our current CHANGES file from the content in > changes-fragments directories with the help of > a template or at least some sort of header / footer that is static. > 5. This script can be called either manually and we commit the resulting > CHANGES file as we like just like the x-forms commits > for documentation plus this script is called by the release scripts from > Daniel as part of the preparation of rolling a > release. I’m keen for a simpler version of this that doesn't create additional steps for people. How about something like this: 1. We create a changes-fragments directory (name to be determined) at the top level. 2. The changes-fragments directory contains the changes for each release and each change entry is a single file. 3. We update the Makefiles so that if any files are found to exist in changes-fragments, those files are moved to the top of CHANGES and then deleted. For all builds except for backports, this will be a silent noop. We would need some kind of token to force it to be a non-noop in release branches. What this means is - after every backport, which won’t conflict because changes is in a unique file as you describe above, the person performs a build to verify that the change is ok. That build automatically sorts out the CHANGES file, and the attempt to commit the backport updates changes. To summarise, with the above, people put changes in changes-fragments directory, and that’s it. Everything else is automated as part of the normal build, no special scripts, no extra steps, nothing for humans to forget. Regards, Graham — smime.p7s Description: S/MIME cryptographic signature
Re: RFC: Documenting changes in the CHANGES file
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, both for reviewing and for actually doing the > backport. How about if we change the way we document changes the following > way: > > 1. We create a changes-fragments directory (name to be determined) at the top > level. > 2. For each release we create a subdirectory such that we end up with the > following structure: > > changes-fragments/ > 2.4.41/ > 2.4.42/ > 2.4.43/ > 2.4.44/ > > 3. Each directory contains the changes for each release and each change entry > is a single file. > 4. We have a script that builds our current CHANGES file from the content in > changes-fragments directories with the help of > a template or at least some sort of header / footer that is static. > 5. This script can be called either manually and we commit the resulting > CHANGES file as we like just like the x-forms commits > for documentation plus this script is called by the release scripts from > Daniel as part of the preparation of rolling a > release. > > > Regards > > Rüdiger
Re: Modern/simpler "proxy-send*" envs in trunk
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 would be to use it when we can't
> determine content-length (because the client body is already chunked
> or because an input filter may change the length of the body).
>
> By doing this we avoid spooling by default, with associated latency,
> and filesystem filling up, and ... you name it.
> By the way we also avoid three `apr_table_get(r->subprocess_env, ..)`
> calls per request, and simplify the code.
>
> For the rare cases (IMHO) where the origin server really does not
> support T-E, there would be "proxy-no-chunked", which would spool when
> necessary.
+1 i have always found this area confusing and fewer spooling cases
(while retaining the spool-to-mem and prefetch stuff) looks good.
I find most "disable chunked encoding" workarounds are just changing a
symptom/error message anyway.
Re: RFC: Documenting changes in the CHANGES file
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 reviewing and for actually doing the > backport. How about if we change the way we document changes the following > way: > > 1. We create a changes-fragments directory (name to be determined) at the top > level. > 2. For each release we create a subdirectory such that we end up with the > following structure: > >changes-fragments/ > 2.4.41/ > 2.4.42/ > 2.4.43/ > 2.4.44/ > > 3. Each directory contains the changes for each release and each change entry > is a single file. > 4. We have a script that builds our current CHANGES file from the content in > changes-fragments directories with the help of >a template or at least some sort of header / footer that is static. > 5. This script can be called either manually and we commit the resulting > CHANGES file as we like just like the x-forms commits >for documentation plus this script is called by the release scripts from > Daniel as part of the preparation of rolling a >release. +1 from me, I don't volonteer for the scripts though :) Regards; Yann.
