On Wed, Mar 25, 2020 at 4:12 PM David Kastrup <[email protected]> wrote: > > [email protected] 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 - [email protected] - http://www.xs4all.nl/~hanwen
