Re: Should we restore manually maintained ChangeLogs

[Dmitry Gutov]

On 03/07/2016 11:06 PM, Eli Zaretskii wrote:

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

Only when merging between branches.

Other than that, only a select group of people needs to bother: those 
who make mistakes, and those who feel a general need to clean up.

As a relatively careful committer, I've only had to correct the entries 
a few times, and I've been enjoying the lack of collisions quite a bit.

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

In the current approach, as well.

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

I think we should wait and see until the work really transitions back to 
master. The motivation must rise.

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

Has the current experiment really sucked too much energy from anyone, 
aside from the implementors? Yes, there is a problem on master, but 
we're still mostly expected to use, and polish, emacs-25.

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

For all we know, they might be thriving despite this practice.

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

Not in my experience either. I've still had collisions, and even when 
git-merge-changelog resolved them, it often put my entry in the middle 
of the file, whereas I usually needed it to be at the top. Leading to 
extra manual labor.

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

It was longer for me. But either way, it's more hassle for a random 
contributor than the current system. If it can be fixed, Someone should.