Re: Should we restore manually maintained ChangeLogs

[Paul Eggert]

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.

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