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

[Han-Wen Nienhuys]

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

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

Local modifications will never produce the right ChangeLog content,
because only we can push commits and tags to savannah.

It has been like this since forever; this mechanism was introduced in
2009, and 2.14.0 (released in 2011) ships a ChangeLog like this in the
out/ directory.

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

--
Han-Wen Nienhuys - address@hidden - http://www.xs4all.nl/~hanwen