[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: Tue, 8 Mar 2016 23:58:07 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0

Eli Zaretskii wrote:
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.

With or without git-merge-changelog?

Without. That program is not normally installed. And I rarely do merges so I don't see why it would help. I recall trying to use it a while ago and had trouble (sorry, do not recall details).

What alternatives that don't "cater to
all sides" would you suggest?  The only one I see is to stop producing
ChangeLog files for the releases.

That's what Guile does and it works OK.

If we want to be more traditional and keep ChangeLog files in releases, we can do what coreutils etc. do. They autogenerate ChangeLog files for releases, but do not put these ChangeLog files in their repositories. They have a way to fix typos in the autogenerated ChangeLog files. It works well enough, as long as typo fixes are rare enough (which they should be). This is all a bit more complicated than what Guile does, but it's simpler than what Emacs does now, and it preserves most of the advantages of what Emacs does now.

Please describe the details of your proposal.

For the more-traditional approach, apply the attached patch to emacs-25, and merge it to master. Other branches can pick it up as needed.

We can easily implement the Guile approach too (it's even simpler), though it sounds like you prefer the more-traditional approach, at least for now.

Attachment: 0001-Simplify-autogeneration-of-top-level-ChangeLog.patch
Description: Text Data

reply via email to

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