You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Stefan Eissing <st...@greenbytes.de> on 2018/03/26 09:23:17 UTC
change the CHANGES
tl;dr
Lets track CHANGES in individual files that can be processed
during merges without conflicts and used in compiling release
documentation more easily.
My case:
CHANGES is very interesting and necessary for documenting releases. The way
we are maintaining it, can be improved.
Case 1, The Backport: if you look at 2.4.x/STATUS, you see a lot of
"trunk applies modulo CHANGES". If it were not for CHANGES, most
backports would be a clean "svn merge -c NNN ^/httpd/httpd/trunk ."
And the problem is not that the text from CHANGES should not be merged.
The problem is that the merge order (e.g. time) is not the same as the
editing order of CHANGES. So, there are conflicts on line numbers which
are simply not relevant.
Case 2, The Release: correct me when I am wrong here, but the release
needs to process and merge CHANGES and do some editing. SECURITY changes
need to be added at some point in time. Manual work that should be
automated.
In order to automate the handling of CHANGES, we need to chop it into
pieces. A CHANGE often aggregates a number of svn revisions, so the svn:log
entries are not a replacement.
Instead, having each CHANGE entry as a separate text file would make
the handling easy. Imagine:
httpd/trunk/changes/bla.txt
httpd/trunk/changes/feature.txt
httpd/trunk/changes/fix123.txt
A tool could then use the output of
> svn info --xml changes/*
to sort it according to last modification date and compile the texts
into a list.
When proposing a backport, you include the revision that created
the "changes" file. So when the backport proposal is merged, the
CHANGE file gets merged as well.
When a release is done, svn move all changes/* into a sub directory,
e.g. changes/2.4.33
WDYT?
Re: change the CHANGES
Posted by Jim Jagielski <ji...@jaguNET.com>.
> On Mar 27, 2018, at 4:58 AM, Stefan Eissing <st...@greenbytes.de> wrote:
>
>
> My main motivation was the RM work. I never did it, but from what
> I see, it involves a lot of manual labor and that is a bit ridiculous
> in our line of work, IMO, YMMV, etc.
>
The effort required by the RM related to CHANGES is
pretty much non-existent. It's basically creating a
copy and then deleting all entries older than the version
we are releasing from within that copy (for the CHANGES_2.4.33
file, for example). Nothing related to manual labor in
editing that file any more so than any one else who
commits a backport.
Re: change the CHANGES
Posted by Stefan Eissing <st...@greenbytes.de>.
I do not fully buy the "we have to do manual editing anyway..." argument,
but we developers can live with the state things are.
My main motivation was the RM work. I never did it, but from what
I see, it involves a lot of manual labor and that is a bit ridiculous
in our line of work, IMO, YMMV, etc.
But I'll rest my case for now, UNLESS/UNTIL a RM steps forward and
rallies us for change. Then I am with her! ;-)
Cheers,
Stefan
> Am 26.03.2018 um 18:29 schrieb Graham Leggett <mi...@sharp.fm>:
>
> On 26 Mar 2018, at 6:13 PM, Jim Jagielski <ji...@jaguNET.com> wrote:
>
>> Is it really all that bothersome and problematic that we need to change
>> things so much? What this does is add complexity and process
>> to the addition of CHANGES where, IMO, it doesn't belong. I
>> can't see adding all this overhead simply to fix cases where someone
>> needs to handle a merge for a back port. The cure seems worse
>> than the disease (and symptoms).
>
> Initially I thought hmmm… interesting, and then I remembered we have MMN bumps that conflict as well and have to be resolved.
>
> I’m also seeing the solution as worse than the problem. The conflict in a backport and how to resolve it are well understood, I’m not seeing the advantage.
>
> Regards,
> Graham
> —
>
Re: change the CHANGES
Posted by Graham Leggett <mi...@sharp.fm>.
On 26 Mar 2018, at 6:13 PM, Jim Jagielski <ji...@jaguNET.com> wrote:
> Is it really all that bothersome and problematic that we need to change
> things so much? What this does is add complexity and process
> to the addition of CHANGES where, IMO, it doesn't belong. I
> can't see adding all this overhead simply to fix cases where someone
> needs to handle a merge for a back port. The cure seems worse
> than the disease (and symptoms).
Initially I thought hmmm… interesting, and then I remembered we have MMN bumps that conflict as well and have to be resolved.
I’m also seeing the solution as worse than the problem. The conflict in a backport and how to resolve it are well understood, I’m not seeing the advantage.
Regards,
Graham
—
Re: change the CHANGES
Posted by Jim Jagielski <ji...@jaguNET.com>.
Is it really all that bothersome and problematic that we need to change
things so much? What this does is add complexity and process
to the addition of CHANGES where, IMO, it doesn't belong. I
can't see adding all this overhead simply to fix cases where someone
needs to handle a merge for a back port. The cure seems worse
than the disease (and symptoms).
All my 2c
> On Mar 26, 2018, at 5:23 AM, Stefan Eissing <st...@greenbytes.de> wrote:
>
> tl;dr
>
> Lets track CHANGES in individual files that can be processed
> during merges without conflicts and used in compiling release
> documentation more easily.
>
>
> My case:
>
> CHANGES is very interesting and necessary for documenting releases. The way
> we are maintaining it, can be improved.
>
> Case 1, The Backport: if you look at 2.4.x/STATUS, you see a lot of
> "trunk applies modulo CHANGES". If it were not for CHANGES, most
> backports would be a clean "svn merge -c NNN ^/httpd/httpd/trunk ."
>
> And the problem is not that the text from CHANGES should not be merged.
> The problem is that the merge order (e.g. time) is not the same as the
> editing order of CHANGES. So, there are conflicts on line numbers which
> are simply not relevant.
>
> Case 2, The Release: correct me when I am wrong here, but the release
> needs to process and merge CHANGES and do some editing. SECURITY changes
> need to be added at some point in time. Manual work that should be
> automated.
>
>
> In order to automate the handling of CHANGES, we need to chop it into
> pieces. A CHANGE often aggregates a number of svn revisions, so the svn:log
> entries are not a replacement.
>
> Instead, having each CHANGE entry as a separate text file would make
> the handling easy. Imagine:
>
> httpd/trunk/changes/bla.txt
> httpd/trunk/changes/feature.txt
> httpd/trunk/changes/fix123.txt
>
> A tool could then use the output of
>> svn info --xml changes/*
>
> to sort it according to last modification date and compile the texts
> into a list.
>
> When proposing a backport, you include the revision that created
> the "changes" file. So when the backport proposal is merged, the
> CHANGE file gets merged as well.
>
> When a release is done, svn move all changes/* into a sub directory,
> e.g. changes/2.4.33
>
> WDYT?
>
>
>
>
Re: change the CHANGES
Posted by Eric Covener <co...@gmail.com>.
On Mon, Mar 26, 2018 at 5:23 AM, Stefan Eissing
<st...@greenbytes.de> wrote:
> tl;dr
>
> Lets track CHANGES in individual files that can be processed
> during merges without conflicts and used in compiling release
> documentation more easily.
>
>
> My case:
>
> CHANGES is very interesting and necessary for documenting releases. The way
> we are maintaining it, can be improved.
>
> Case 1, The Backport: if you look at 2.4.x/STATUS, you see a lot of
> "trunk applies modulo CHANGES". If it were not for CHANGES, most
> backports would be a clean "svn merge -c NNN ^/httpd/httpd/trunk ."
>
> And the problem is not that the text from CHANGES should not be merged.
> The problem is that the merge order (e.g. time) is not the same as the
> editing order of CHANGES. So, there are conflicts on line numbers which
> are simply not relevant.
>
> Case 2, The Release: correct me when I am wrong here, but the release
> needs to process and merge CHANGES and do some editing. SECURITY changes
> need to be added at some point in time. Manual work that should be
> automated.
>
>
> In order to automate the handling of CHANGES, we need to chop it into
> pieces. A CHANGE often aggregates a number of svn revisions, so the svn:log
> entries are not a replacement.
>
> Instead, having each CHANGE entry as a separate text file would make
> the handling easy. Imagine:
>
> httpd/trunk/changes/bla.txt
> httpd/trunk/changes/feature.txt
> httpd/trunk/changes/fix123.txt
>
> A tool could then use the output of
>> svn info --xml changes/*
>
> to sort it according to last modification date and compile the texts
> into a list.
>
> When proposing a backport, you include the revision that created
> the "changes" file. So when the backport proposal is merged, the
> CHANGE file gets merged as well.
>
> When a release is done, svn move all changes/* into a sub directory,
> e.g. changes/2.4.33
>
> WDYT?
I'd give it a try. Would the release branches remove the changes/* and
merge into a flat file at release time? Otherwise, it would get a bit
unruly as they collected.