Issue 547810069: Trim unused toplevel targets. (Closed)
|
Created:
4 years ago by hanwenn Modified:
4 years ago CC:
lilypond-devel_gnu.org Visibility:
Public. |
DescriptionTrim unused toplevel targets.
Patch Set 1 #
Total comments: 1
MessagesTotal messages: 8
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?
Sign in to reply to this 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? 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.
Sign in to reply to this message.
hanwenn@gmail.com 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. 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. -- David Kastrup
Sign in to reply to this message.
On Wed, Mar 25, 2020 at 4:12 PM David Kastrup <dak@gnu.org> wrote: > > hanwenn@gmail.com 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/... 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 - hanwenn@gmail.com - http://www.xs4all.nl/~hanwen
Sign in to reply to this message.
Han-Wen Nienhuys <hanwenn@gmail.com> writes: > On Wed, Mar 25, 2020 at 4:12 PM David Kastrup <dak@gnu.org> wrote: >> >> hanwenn@gmail.com 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/... > > 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 <janneke@gnu.org> 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".
Sign in to reply to this message.
On Thu, Mar 26, 2020 at 12:26 PM David Kastrup <dak@gnu.org> 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/... > > > > 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 <janneke@gnu.org> > 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/ac242ed3843e127c1e2e506ecfd1a4552a... The output looks like 2020-03-01 Werner Lemberg <wl@gnu.org> Issue 5795: NR: Improve color table layout 2020-02-29 Dan Eble <nine.fierce.ballads@gmail.com> 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 - hanwenn@gmail.com - http://www.xs4all.nl/~hanwen
Sign in to reply to this message.
commit 0755e2f3dbb99ac256fb447d6ed14d3fe87b8ab5 Author: Han-Wen Nienhuys <hanwen@lilypond.org> Date: Sun Mar 22 00:16:36 2020 +0100 Trim unused toplevel targets. https://sourceforge.net/p/testlilyissues/issues/5861 http://codereview.appspot.com/547810069
Sign in to reply to this message.
|
||||||||||||||||||||||||||||||||||||||||||||||
