Re: Should we restore manually maintained ChangeLogs

[Eli Zaretskii]

> Cc: address@hidden, address@hidden
> From: Paul Eggert <address@hidden>
> Date: Mon, 7 Mar 2016 11:02:02 -0800
> 
> Maintaining ChangeLog files by hand with each commit makes it harder
> to merge changes due to the inevitable collisions with ChangeLog
> files.

Incorrect!  And the current situation creates _more_ collisions, not
less!

> 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.

We don't have to be better than the other prominent GNU projects.

> > 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.

But ChangeLog mistakes can be easily fixed.

> > 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.)

We don't know how, and we don't have anyone who is motivated enough to
do that.  And even if and when we do have some solution, it is likely
to be inconvenient and unreliable.

> 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.

Let other projects invent those schemes and test-drive them.  Enough
with these experiments!  They draw the last drops of energy from us,
and they avert the few last veteran contributors we have left.

> > 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.

That's not a bad thing in itself.  The point is, these procedures
work, and all those projects are alive and kicking, and actually make
more frequent releases than we do.

> > 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

Oh, yes, it does.

> 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.

It's a 5-sec configuration, let's not make a mountain out of a
molehill.

> 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.

There's no need for a maintainer, as there are no problems.  I'm using
that program all the time.