Re: Should we restore manually maintained ChangeLogs

[Eli Zaretskii]

> Cc: address@hidden, address@hidden, address@hidden
> From: Paul Eggert <address@hidden>
> Date: Mon, 7 Mar 2016 15:31:54 -0800
> 
> 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.

With or without git-merge-changelog?

If you have git-merge-changelog installed, what kind of screwups did
you see with ChangeLogs?  (I didn't see even one, in all the years I
use Git.)

>  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.

The current approach completely breaks down when more than one branch
is active.  So there's no baby in that 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.

Not sure what you mean here.  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.

>     ChangeLog mistakes can be easily fixed. 
> 
> That's true under both the old and the new regimes.

No, it isn't.  Definitely not with two branches.

>     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.

Don't know what hides behind "etc", but the rest are much smaller
projects, which are all in maintenance mode, and have a very small
number of active committers (of which you personally are a significant
fraction ;-).  They also don't use branches, at least not as much as
we do.  So I don't see how the experience of these projects is more
relevant to us than that of GCC, GDB, Binutils, and glibc.

> I could fairly easily change the master branch to do that.

Please describe the details of your proposal.  Also, please tell what
do you suggest doing on the release branches.

> 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".

As I said, tossing ChangeLog files entirely would indeed solve the
problems, but it's a sure path to further deterioration in the quality
of log messages.  It is easy to keep the quality in a project that has
a small number of committers who are veteran GNU developers (Guile has
1 frequent committer on master, and 3 on stable).  That's not our
case.

> 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.

Any suggested approach should support not only the current emacs-25
branch, but also the future release branches, i.e. it should continue
working when we cut the emacs-26 branch in the future.  It should also
be reliable, and not require manual labor for fixing mistakes in the
log messages, beyond the fix itself.

>     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.

XEmacs is not that different from Grep or Sed.  Sed, for example, saw
just 30 commits during all of the last year.

> 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.

It's the other way around, actually: the current situation requires
more labor from us to get it right, so our lack of resources should
lead us to the opposite conclusion.

>         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. 

Fixing its mistakes involves moving an entry to a different place,
that's all.  Easy done, and even if not done, it's not a disaster, as
the information is there anyway.