> 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 by the RM related to CHANGES is
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, et
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 overhead simply to fi
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 po
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 and necessary for documenting
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