[Top][All Lists]

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

Re: Should we restore manually maintained ChangeLogs

From: Paul Eggert
Subject: Re: Should we restore manually maintained ChangeLogs
Date: Mon, 7 Mar 2016 11:02:02 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0

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.

reply via email to

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