Re: change the CHANGES

> On Mar 27, 2018, at 4:58 AM, Stefan Eissing > 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

Re: change the CHANGES

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,

Re: change the CHANGES

On 26 Mar 2018, at 6:13 PM, Jim Jagielski 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

Re: change the CHANGES

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

Re: change the CHANGES

On Mon, Mar 26, 2018 at 5:23 AM, Stefan Eissing 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

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