Re: Should we restore manually maintained ChangeLogs

[Paul Eggert]

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
> > files.
> Incorrect!  And the current situation creates _more_ collisions, not
> less!

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.