[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Should we restore manually maintained ChangeLogs

From: Dmitry Gutov
Subject: Re: Should we restore manually maintained ChangeLogs
Date: Mon, 7 Mar 2016 23:42:33 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0

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

Incorrect!  And the current situation creates _more_ collisions, not

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

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]