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

[Han-Wen Nienhuys]

On Thu, Mar 26, 2020 at 12:26 PM David Kastrup <address@hidden> wrote:
> >> > 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?

The deeper reason is that I'm trying to improve the build system. This
will take the form of a rewrite.  In that context, it's useful to
remove as much unnecessary cruft from the current build system as
possible, so it is clear what is needs to be redone. The
almost-useless ChangeLog in a non-discoverable place is an example of
such cruft.

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

This only true in theory. In practice, the ChangeLog doesn't provide
enough information to reconstruct what happened to a file. If a
distribution packager encounters a problem, they are much more likely
to use git-blame and git-log to find out what changed, for what
reason.

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

I think you are saying here, that it's OK for us to remove the
ChangeLog from the perspective of GNU standards and our license.

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

It involves a 300 line perl program,

https://github.com/emacs-mirror/emacs/blob/ac242ed3843e127c1e2e506ecfd1a4552a2a8c44/build-aux/gitlog-to-changelog

The output looks like

2020-03-01  Werner Lemberg  <address@hidden>

        Issue 5795: NR: Improve color table layout

2020-02-29  Dan Eble  <address@hidden>

        Issue 5790/8: Rational: to_int () becomes trunc_int ()
        ... and returns I64 like num () and den ().

        Issue 5790/7: Rational: disable implicit conversion to double
        This helps emphasize places where exactness might be lost.

ie. the 'changelog' doesn't list the files that were affected by the
changes, so it seems fairly useless to me.

I stand by my proposal to remove our current support for this.

If anyone else cares enough about GNU style ChangeLogs, they can
propose a change to re-introduce them in a more useful form.

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