[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 15:31:54 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0

On 03/07/2016 01: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

My own experience is otherwise. For the kinds of development I do, I rarely see ChangeLog screwups now, whereas I used to see them routinely. I far prefer the current approach. Of course our approach can be improved (in particular merging from emacs-25 to master doesn't work well now), but let's not throw out the baby with the bathwater.

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

I'd be happy if we were merely as good as the other prominent GNU projects that generate ChangeLog entries automatically. As things stand, due to our attempt to cater to all sides of this disagreement, we have an approach that satisfies nobody.

ChangeLog mistakes can be easily fixed.

That's true under both the old and the new regimes.

Let other projects invent those schemes and test-drive them. Enough with these experiments!

I'd rather just do what coreutils, grep, tar, etc. use. It's just as simple for ordinary committers and it would not involve duplication in patches or experimentation with maintenance procedures. I could fairly easily change the master branch to do that.

Even simpler would be to do what Guile does: it dispenses with ChangeLogs entirely. With Guile if you want something like a ChangeLog you run "git log".

If neither of the above two approaches suffice, we can always fall back on my previous email's proposal. It's not that experiemental, as it says to use the new produre on master and the old procedure on emacs-25. The new procedure works well enough within a single master branch.

Of all the above, though, Guile's approach is the simplest and is probably the best for us overall.

these procedures work, and all those projects are alive and kicking, and actually make more frequent releases than we do.

XEmacs is not really alive and kicking.

Projects like GCC and glibc have more resources than we do, and can afford to insist on more-expert contributions that involve harder-to-generate patch formats. We do not have that luxury.

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, or in Dmitry's. It's a fine program, but it sometimes makes mistakes and they can be a pain to fix.

reply via email to

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