Re: Should we restore manually maintained ChangeLogs

[Paul Eggert <eggert@cs.ucla.edu>]

Let's not go back. Maintaining ChangeLog files by hand with each commit 
makes it harder to merge changes due to the inevitable collisions with 
ChangeLog files. Although other projects that continue to use this older 
style (e.g., glibc) work around the problem by requiring contributors to 
deal with the hassles, this is one more barrier to contributions and 
there are better alternatives.

On 03/07/2016 09:50 AM, Eli Zaretskii wrote:
> mistakes in the log messages are not corrected

This is a problem regardless of whether ChangeLog files are updated by 
each commit. Under either approach, contributors often make mistakes in 
their ChangeLog entries, and don't bother to fix them because (let's 
face it) ChangeLog entries are low priority.

> there's an unsolved problem of merging from the release branch to master.

We can solve that problem. (It hasn't been high priority to fix.)

Here's one simple way to fix it: run the automated ChangeLog generator 
only on the master branch, as was originally intended, and use manual 
updates to ChangeLog files in other branches.  (The hassle of manually 
maintaining ChangeLog files on emacs-25 will serve to discourage further 
changes to the emacs-25 branch, which is arguably a good thing. :-) We 
can come up with a better approach later.

> Other projects maintain ChangeLog files in the repository: GCC, 
> Binutils, GDB, glibc, Texinfo, XEmacs, to name just those that I know 
> about.

These are all longstanding projects that haven't changed their 
procedures for ages. New projects don't do this, by and large. (XEmacs 
has gone quiescent, as I understand it, so it's not a good example here.)

> We have maintained ChangeLog files in the repo for years, and I don't 
> remember this ever being a problem, provided that a proper merge tool 
> (git-merge-changelog for Git) is installed. 

I often ran into problems. Yes, git-merge-changelog should reduce the 
number of merge conflicts, but it doesn't eliminate them, and things can 
be even more confusing when there are conflicts anyway. Also, requiring 
git-merge-changelog means that many contributors would have to worry 
about installing and configuring git-merge-changelog, which would be 
more of a hassle for recruiting contributors. In practice under the old 
approach many contributors didn't bother, dealt with the merge conflicts 
by hand, and all too often messed up.

I should mention that git-merge-changelog effectively has no maintainer 
now; if we run into a problem with it, we'll have to maintain it ourselves.