Re: Trim unused toplevel targets. (issue 547810069 by address@hidden)

[David Kastrup]

Han-Wen Nienhuys <address@hidden> writes:

> On Wed, Mar 25, 2020 at 4:12 PM David Kastrup <address@hidden> wrote:
>>
>> address@hidden writes:
>>
>> > Reviewers: lemzwerg,
>> >
>> > Message:
>> > On 2020/03/22 05:51:34, lemzwerg wrote:
>> >> LGTM
>> >>
>> >> https://codereview.appspot.com/547810069/diff/575870045/GNUmakefile.in
>> >> File GNUmakefile.in (right):
>> >>
>> >>
>> > https://codereview.appspot.com/547810069/diff/575870045/GNUmakefile.in#newcode26
>> >> GNUmakefile.in:26: RELEASE_FILES = RELEASE-COMMIT
>> >> Many GNU packages auto-generate a ChangeLog file from the git commit
>> > messages.
>> >> Shall we do something similar?
>> >
>> > What is the ChangeLog used for these days?
>>
>> Checking what changes are relevant for the distributed version.
>>
>> > Many GNU packages haven't been with the times. Git is now 14 years old.
>> > I people want to know what changed, they can read the man page to
>> > git-log.
>>
>> That assumes that they don't have an official and versioned distribution
>> of LilyPond (or of some fork of it) but rather a clone of the repository
>> corresponding to their version of Git.  The GPL does not guarantee that
>> modified source comes with full repository access to back it.  Merely
>> the _current_ corresponding source.
>>
>> That's the reason "many GNU packages auto-generate a ChangeLog file from
>> the git commit messages".  The decision to do that has been made after
>> considerable discussion and the respective tools have been developed.
>
>
> This is all nice and dandy, but
>
> $ tar tfz ~/Downloads/lilypond-2.20.0.tar.gz lilypond-2.20.0/|grep -i 
> changelog
> lilypond-2.20.0/out/ChangeLog
> lilypond-2.20.0/Documentation/misc/ChangeLog-2.10
> lilypond-2.20.0/Documentation/misc/ChangeLog-1.5
> lilypond-2.20.0/Documentation/misc/ChangeLog-2.3
> lilypond-2.20.0/Documentation/misc/ChangeLog-2.1
>
> ie. the ChangeLog is in a place where nobody can find it, and

That would be reason to fix it?

> $ cat lilypond-2.20.0/out/ChangeLog
> See 
> http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=log;h=refs/tags/release/2.20.0-1
>
> it just contains a link, to a paged  version of our log. Good luck
> making sense of that.

This is the (intended) consequence of
commit 525fcaecb829de8c680ad36151d8532da8e35219
Author: Jan Nieuwenhuizen <address@hidden>
Date:   Wed Jan 14 12:24:47 2009 +0100

    Add missing ChangeLog file with web marker only.

I agree that this does not make a whole lot of sense since it cannot
provide any useful information for anything not released from the
central repository.

Autogenerating the ChangeLog, in contrast, would decouple the tarball
from the Git repository.

> Given that nobody has complained about this undiscoverable and useless
> ChangeLog for over 9 years, I think it is safe to remove it.

It's not useless as such (the link is useful) but it is useless for the
purpose of providing a change history if anybody desires to work with
it.  It is worth noting that the explicit requirement to mark/list all
changes prominently is part of GPLv2 but no longer of GPLv3.

GNU Coding standards
<https://www.gnu.org/prep/standards/standards.html#Change-Log-Concepts>
state:

    Instead of using a file named ChangeLog, you can record the change
    log information as log entries in a version control system such as
    RCS or CVS. This can be converted automatically to a ChangeLog file
    using rcs2log; in Emacs, the command C-x v a (vc-update-change-log)
    does the job.

The choice of listed version control systems makes clear that this text
likely comes from a time before distributed version control systems.

I know that Emacs autogenerates its (GNU standard format) ChangeLog
files from the Git commit messages, but I think that this requires
generally adhering to the kind of formatting you want to end up seeing
in the ChangeLog.

>> It's not like decision and implementation of such a policy would
>> happen in a vacuum and be unprecedented, so the cost of implementing
>> such a policy would be considerably more moderate than if we had to
>> do it from scratch.
>
> I think you are overestimating the amount of careful thought that went
> into this.

The Emacs developer community is large enough that one can with some
confidence assume that not all of them are idiots.  And if they managed
to converge on a solution that they consider reasonably painless for
that purpose, at least taking a look does not seem outlandish.

-- 
David Kastrup
My replies have a tendency to cause friction.  To help mitigating
damage, feel free to forward problematic posts to me adding a subject
like "timeout 1d" (for a suggested timeout of 1 day) or "offensive".