Re: Should we restore manually maintained ChangeLogs

[Eli Zaretskii <eliz@gnu.org>]

> Cc: mthl@gnu.org, johnw@gnu.org, emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Mon, 7 Mar 2016 23:42:33 +0200
> 
>         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!
> 
> Only when merging between branches.

It doesn't work very well even on a single branch.  With two branches,
it completely breaks down.

We do want to work on multiple branches, don't we?  We discussed how
to make more frequent releases, and perhaps have 3 branches for even
more flexible development and release schedule.  All of that would be
impossible because of this tiny but annoying PITA.  Do we really want
to continue wasting energy on fixing something that wasn't such a big
problem to begin with?

> Other than that, only a select group of people needs to bother: those who make mistakes, and those who feel a general need to clean up.

See, that's the crux of the issue: do we or don't we care about the
need to clean up our ChangeLogs?  If we don't, then why bother
maintaining them?

You (and some others) say the format and the content in the log
messages are important, and I agree.  But if we do care about them,
how can we NOT clean them up?  Having them in their current state
means they cannot be trusted, which is worse than not having them at
all.

> As a relatively careful committer, I've only had to correct the entries a few times, and I've been enjoying the lack of collisions quite a bit.

Yes, a few of us don't need any corrections.  But enough of us do, and
that's where the problem lies.  It is that problem that we need to
fix.  Leaving it unfixed makes your accurate work unreliable as well.

>     But ChangeLog mistakes can be easily fixed.
> 
> In the current approach, as well.

Only on a single branch, and even there this is not done enough.  We
all relied on Glenn to do that behind the scenes.  Now Glenn gave up
in despair, so things will degrade from now on.

>     We don't know how, and we don't have anyone who is motivated enough to
>     do that.  And even if and when we do have some solution, it is likely
>     to be inconvenient and unreliable.
> 
> I think we should wait and see until the work really transitions back to master. The motivation must rise.

The release branch will remain active for quite some time: we have
just started a new major version.  And if we want more frequent
releases, we should strive to have an active release branch at all
times.  So I don't think we can wait; waiting will not solve anything,
it will just make the current problems bigger and harder to solve.

>     Let other projects invent those schemes and test-drive them.  Enough
>     with these experiments!  They draw the last drops of energy from us,
>     and they avert the few last veteran contributors we have left.
> 
> Has the current experiment really sucked too much energy from anyone, aside from the implementors?

Why do you think Glenn gave up?

>     That's not a bad thing in itself.  The point is, these procedures
>     work, and all those projects are alive and kicking, and actually make
>     more frequent releases than we do.
> 
> For all we know, they might be thriving despite this practice.

Nothing wrong with that.

>         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 either. I've still had collisions, and even when git-merge-changelog resolved them, it often put my entry in the middle of the file, whereas I usually needed it to be at the top. Leading to extra manual labor.

That extra manual labor is very small, and it's still a rare case to
have that.  A small price to pay for a clean and reliable solution.

>         requiring git-merge-changelog means that many contributors would
>         have to worry about installing and configuring git-merge-changelog,
>         which would be more of a hassle for recruiting contributors.
> 
>     It's a 5-sec configuration, let's not make a mountain out of a
>     molehill.
> 
> It was longer for me. But either way, it's more hassle for a random contributor than the current system.

The current system is much more hassle for non-random contributors, so
much so that we risk losing them, something we cannot afford.

> If it can be fixed, Someone should.

Let that Someone step forward, then, and speak up.  We have been
waiting for that for the past year, so I'm not holding my breath now.