You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Yann Ylavic <yl...@gmail.com> on 2020/06/01 11:23:52 UTC
Re: RFC: Documenting changes in the CHANGES file
On Fri, May 29, 2020 at 9:30 PM Ruediger Pluem <rp...@apache.org> 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.
Re: RFC: Documenting changes in the CHANGES file
Posted by Ruediger Pluem <rp...@apache.org>.
On 6/8/20 10:20 AM, Ruediger Pluem wrote:
>
>>
>
> Thanks for all the feedback. I try to work out something more detailed aka patch that we can discuss then.
>
Done as r1879822. Happy to get some feedback.
Regards
Rüdiger
Re: RFC: Documenting changes in the CHANGES file
Posted by Ruediger Pluem <rp...@apache.org>.
On 6/2/20 2:17 PM, Stefan Eissing wrote:
>
>> Am 02.06.2020 um 14:11 schrieb Daniel Ruggeri <da...@bitnebula.com>:
>>
>> On 6/1/2020 6:23 AM, Yann Ylavic wrote:
>>> On Fri, May 29, 2020 at 9:30 PM Ruediger Pluem <rp...@apache.org>
>>> 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.
>>>
>> Hi, Yann;
>>
>> I'm open to whatever... and don't mind writing or tweaking scripts once we decide on an approach :-)
>>
>> While we are discussing ideas in this neighborhood, one thing to keep in mind is that during release of security fixes, sometimes there are items added to CHANGES and sometimes CHANGES is modified to add CVE information. There have been minor bumps in the road where these patches don't always apply cleanly. So, if possible, it would be great to consider. There may be nothing to do, though, since that happens waaaaay after backport.
>>
>
>
> +1 from me as well. CHANGES is annoying atm, any automation appreciated.
>
Thanks for all the feedback. I try to work out something more detailed aka patch that we can discuss then.
Regards
Rüdiger
Re: RFC: Documenting changes in the CHANGES file
Posted by Stefan Eissing <st...@greenbytes.de>.
> Am 02.06.2020 um 14:11 schrieb Daniel Ruggeri <da...@bitnebula.com>:
>
> On 6/1/2020 6:23 AM, Yann Ylavic wrote:
>> On Fri, May 29, 2020 at 9:30 PM Ruediger Pluem <rp...@apache.org>
>> 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.
>>
> Hi, Yann;
>
> I'm open to whatever... and don't mind writing or tweaking scripts once we decide on an approach :-)
>
> While we are discussing ideas in this neighborhood, one thing to keep in mind is that during release of security fixes, sometimes there are items added to CHANGES and sometimes CHANGES is modified to add CVE information. There have been minor bumps in the road where these patches don't always apply cleanly. So, if possible, it would be great to consider. There may be nothing to do, though, since that happens waaaaay after backport.
>
+1 from me as well. CHANGES is annoying atm, any automation appreciated.
Cheers, Stefan
Re: RFC: Documenting changes in the CHANGES file
Posted by Daniel Ruggeri <da...@bitnebula.com>.
On 6/1/2020 6:23 AM, Yann Ylavic wrote:
> On Fri, May 29, 2020 at 9:30 PM Ruediger Pluem <rp...@apache.org> 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.
Hi, Yann;
I'm open to whatever... and don't mind writing or tweaking scripts once
we decide on an approach :-)
While we are discussing ideas in this neighborhood, one thing to keep in
mind is that during release of security fixes, sometimes there are items
added to CHANGES and sometimes CHANGES is modified to add CVE
information. There have been minor bumps in the road where these patches
don't always apply cleanly. So, if possible, it would be great to
consider. There may be nothing to do, though, since that happens waaaaay
after backport.
--
Daniel Ruggeri