Re: Issue 5862: Prefer astyle 3.1 and update clang-format options (issue 551640043 by nine.fierce.ball...@gmail.com)

[nine . fierce . ballads]

On 2020/03/26 11:35:11, dak wrote:
> On 2020/03/26 01:25:57, Dan Eble wrote:
> > It's worth emphasizing this: even with these improvements to the
clang-format
> > configuration, those who use clang-format will introduce a truckload
of
> > differences from the traditional indentation.
...
> correctly.  Is there some reasonable hope that we could boil down a
"common
> denominator" style where alternately applying clang formatting and
fixcc would
> end up with a fixed end result rather than some cycle?

I have not familiarized myself with the options of astyle, but at
present, I'm not optimistic.

Still, as I worked on this change, I noticed a couple of common and
simple things that could take another bite out of the differences:

1. space or no space after the "operator" keyword
2. space or no space after "template" in "template"


https://codereview.appspot.com/551640043/

Re: 2.21.0 and announcements

[Davide Liessi]

Dear David,

Il giorno gio 26 mar 2020 alle ore 17:11 David Kastrup  ha 
scritto:
> I think
> we should point out on our download page that the GUB-provided
> installers are _only_ for 32bit MacOSX, and that separate downloads may
> be provided elsewhere (possibly linking to Marnen's page

I agree.
Patch attached (based on master), but I haven't tested it.

> in the hope
> that it does not get overloaded?).

Marnen's builds are hosted on Bintray, whose free plan allows
downloads for up to 1TB/month: how much traffic do we expect?

Best wishes.
Davide
From 9322e358b2781dd58e393afaa5acd92956e0537a Mon Sep 17 00:00:00 2001
From: Davide Liessi 
Date: Thu, 26 Mar 2020 19:50:42 +0100
Subject: [PATCH] Web: add 64-bit Mac download links

Current Intel Mac builds are 32-bit and cannot run on Mac's latest
version 10.15.  Links to Marnen Laibow-Koser's 64-bit builds are
added in the download pages.  The existing link descriptions are
updated to be more precise on supported OS versions.
---
 Documentation/web/community.itexi  |  4 
 Documentation/web/download.itexi   | 14 +++---
 scripts/build/create-weblinks-itexi.py |  4 ++--
 3 files changed, 17 insertions(+), 5 deletions(-)

diff --git a/Documentation/web/community.itexi b/Documentation/web/community.itexi
index c3ebab18e5..2cd060f601 100644
--- a/Documentation/web/community.itexi
+++ b/Documentation/web/community.itexi
@@ -635,6 +635,10 @@ the latest binary:
 
 @downloadDevelDarwinPPC
 
+@c file name is unpredictable, linking to main page
+@uref{https://bintray.com/marnen/lilypond-darwin-64,
+Mac OS X x86 64-bit (unofficial)}
+
 @downloadDevelWindows
 
 @downloadDevelSource
diff --git a/Documentation/web/download.itexi b/Documentation/web/download.itexi
index c3eb4fa2c5..f48b3cb538 100644
--- a/Documentation/web/download.itexi
+++ b/Documentation/web/download.itexi
@@ -263,17 +263,25 @@ acknowledged.
 @item
 @sourceimage{logo-macosx,,,}
 @downloadStableDarwinNormal
-For MacOS X 10.4 or higher, running on Intel CPUs (if in doubt,
-use this).
+For Mac OS X 10.4--10.5 running on Intel CPUs and Mac OS X
+10.6--10.14 (for 10.15 see below).
 
 
 @item
 @sourceimage{logo-macosx,,,}
 @downloadStableDarwinPPC
-For MacOS X 10.4 or higher, running on G3 and G4 CPUs (old Apple
+For Mac OS X 10.4--10.5 running on G3 and G4 CPUs (old Apple
 computers).
 
 
+@item
+@sourceimage{logo-macosx,,,}
+@c file name is unpredictable, linking to main page
+Unofficial 64-bit application bundles for macOS 10.15 are
+available at
+@uref{https://bintray.com/marnen/lilypond-darwin-64}.
+
+
 @end itemize
 
 @subsubheading Install
diff --git a/scripts/build/create-weblinks-itexi.py b/scripts/build/create-weblinks-itexi.py
index 3ab08061d3..7bba1332c7 100644
--- a/scripts/build/create-weblinks-itexi.py
+++ b/scripts/build/create-weblinks-itexi.py
@@ -466,9 +466,9 @@ def make_all_downloads(macroName, version):
 "freebsd-64.sh", version, "1", "FreeBSD amd64")
 
 make_download("download"+macroName+"DarwinNormal", "darwin-x86/",
-"darwin-x86.tar.bz2", version, "1", "MacOS X x86")
+"darwin-x86.tar.bz2", version, "1", "Mac OS X x86 32-bit")
 make_download("download"+macroName+"DarwinPPC", "darwin-ppc/",
-"darwin-ppc.tar.bz2", version, "1", "MacOS X PPC")
+"darwin-ppc.tar.bz2", version, "1", "Mac OS X PPC")
 
 make_download("download"+macroName+"Windows", "mingw/",
 "mingw.exe", version, "1", "Windows")
-- 
2.25.1

Re: 2.21.0 and announcements

[Jean-Charles Malahieude]

Le 26/03/2020 à 18:38, David Kastrup a écrit :

Jean-Charles Malahieude  writes:


Would you mind letting me run translation-status and merge updated
docs from Franscisco and myself into staging?


I would not mind at all.  In fact, I'd have planned to do so myself, but
certainly would be glad for you to do it.



Done and pushed.

Please don't forget to cherry-pick from stable/2.20 the updated po files 
before the release process, otherwise the work will get lost (ca, da, 
de, eo, es, fr, it, ja, nl, sv).


Cheers,
--
Jean-Charles

Re: 2.21.0 and announcements

[David Kastrup]

Jean-Charles Malahieude  writes:

> Le 26/03/2020 à 17:11, David Kastrup a écrit :
>> Because once the big announcements are made, we want people to
>> actually
>> be able to work with what they find on the web page.
>> We can release 2.21.0 prior to that, of course, since the web page
>> updates are (I think) independent from releases.
>> 
>
> Would you mind letting me run translation-status and merge updated
> docs from Franscisco and myself into staging?

I would not mind at all.  In fact, I'd have planned to do so myself, but
certainly would be glad for you to do it.

-- 
David Kastrup

Re: 2.21.0 and announcements

[Werner LEMBERG]

>> We can release 2.21.0 prior to that, of course, since the web page
>> updates are (I think) independent from releases.
> 
> Would you mind letting me run translation-status and merge updated
> docs from Franscisco and myself into staging?

And doing an LSR import would be nice, too – some updated snippets are
necessary for correct documentation.


Werner

Re: 2.21.0 and announcements

[Jean-Charles Malahieude]

Le 26/03/2020 à 17:11, David Kastrup a écrit :


Because once the big announcements are made, we want people to actually
be able to work with what they find on the web page.

We can release 2.21.0 prior to that, of course, since the web page
updates are (I think) independent from releases.



Would you mind letting me run translation-status and merge updated docs 
from Franscisco and myself into staging?


Cheers,
--
Jean-Charles

Re: 2.21.0 and announcements

[Urs Liska]

Am 26. März 2020 17:46:07 MEZ schrieb Carl Sorensen :
>
>
>On 3/26/20, 10:12 AM, "lilypond-devel on behalf of David Kastrup"
>d...@gnu.org> wrote:
>
>
> So it's time to roll out 2.21.0 and I think the build instructions are
>   ok-ish for that.  We don't clarify the relations/recommendations for
>Guile-1.8/2.x but that relation/recommendation is currently in flux and
>this is an unstable release.
>
>We still haven't made the "big" 2.20 announcement, and 2.21.0 being out
>  would make the web page consistent with regard to stable/unstable, so
>that would seem like a good opportunity.
>
>Except that the web page currently is broken with some Python2/3
>problems, and that people are hitting a roadblock with MacOSX.  I think
>we should point out on our download page that the GUB-provided
>installers are _only_ for 32bit MacOSX, and that separate downloads may
>   be provided elsewhere (possibly linking to Marnen's page in the hope
>that it does not get overloaded?).
>
>I can provide a pretty robust mirror of Marnen's page if need be.  It
>would be on my university server with lots of bandwidth.

Could we do that too, Ralf, Moritz?
>
>Thanks,
>
>Carl
>

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

Re: 2.21.0 and announcements

[Carl Sorensen]

On 3/26/20, 10:12 AM, "lilypond-devel on behalf of David Kastrup" 
 
wrote:


So it's time to roll out 2.21.0 and I think the build instructions are
ok-ish for that.  We don't clarify the relations/recommendations for
Guile-1.8/2.x but that relation/recommendation is currently in flux and
this is an unstable release.

We still haven't made the "big" 2.20 announcement, and 2.21.0 being out
would make the web page consistent with regard to stable/unstable, so
that would seem like a good opportunity.

Except that the web page currently is broken with some Python2/3
problems, and that people are hitting a roadblock with MacOSX.  I think
we should point out on our download page that the GUB-provided
installers are _only_ for 32bit MacOSX, and that separate downloads may
be provided elsewhere (possibly linking to Marnen's page in the hope
that it does not get overloaded?).

I can provide a pretty robust mirror of Marnen's page if need be.  It would be 
on my university server with lots of bandwidth.

Thanks,

Carl

Re: Add dynamic-interface to keepAliveInterfaces (issue 553760043 by j...@abou-samra.fr)

[Werner LEMBERG]

>> Never seen that, AFAIK.  Can you provide a link to such a score?
> 
> I can certainly imagine that sort of things, in an orchestral score
> simple enough that all instruments share the same dynamics (as was
> common until the late 18th century), and where the LilyPonder may
> want to store all that in a shared variable, including for systems
> where for example all the wind instruments are tacet.

Well, sharing is OK, but displaying?  Are you really saying there
exist scores that have staff lines only with rests, and which also
have dynamics like 'f' or 'p'?  Besides not making any sense, it would
completely confuse the player IMHO.


Werner

Re: Add dynamic-interface to keepAliveInterfaces (issue 553760043 by j...@abou-samra.fr)

[v . villenave]

On 2020/03/26 12:52:29, wl_gnu.org wrote:
> Never seen that, AFAIK.  Can you provide a link to such a score?

I can certainly imagine that sort of things, in an orchestral score
simple enough that all instruments share the same dynamics (as was
common until the late 18th century), and where the LilyPonder may want
to store all that in a shared variable, including for systems where for
example all the wind instruments are tacet.

OTOH, we may also decide that users advanced enough to typeset a full
partitura are knowledgeable enough to know how to set their own
keepAliveInterfaces.

BTW (on an unrelated note), I’ve just noticed that there’s something
weird happening with some stem columns when dynamics are attached to
spacer rests:
https://sourceforge.net/p/testlilyissues/issues/4691/#cc82

V.

https://codereview.appspot.com/553760043/

Re: Patch on dynamics and \RemoveEmptyStaves

[Valentin Villenave]

On 3/26/20, James Lowe  wrote:
> Yes David K is correct. If someone could take a look at the scripts in
> git-cl and get them working smoothly again (there are other errors
> reported on this list about git-cl) it would be a boon to the dev team.

By the way (this is not directly related but may orient how we decide
to address git-cl’s future), do note that git-cl will apparently
remain python2-only for the foreseeable future:
https://github.com/rietveld-codereview/rietveld/issues/486
which will become more and more of a hindrance as python 2 gets phased
out, and python 3, increasingly ubiquitous.

V.

Re: 2.21.0 and announcements

[Urs Liska]

Am 26. März 2020 17:11:36 MEZ schrieb David Kastrup :
>
>So it's time to roll out 2.21.0 and I think the build instructions are
>ok-ish for that.  We don't clarify the relations/recommendations for
>Guile-1.8/2.x but that relation/recommendation is currently in flux and
>this is an unstable release.
>
>We still haven't made the "big" 2.20 announcement, and 2.21.0 being out
>would make the web page consistent with regard to stable/unstable, so
>that would seem like a good opportunity.
>
>Except that the web page currently is broken with some Python2/3
>problems, and that people are hitting a roadblock with MacOSX.  I think
>we should point out on our download page that the GUB-provided
>installers are _only_ for 32bit MacOSX, and that separate downloads may
>be provided elsewhere (possibly linking to Marnen's page in the hope
>that it does not get overloaded?).
>
>Because once the big announcements are made, we want people to actually
>be able to work with what they find on the web page.
>
>We can release 2.21.0 prior to that, of course, since the web page
>updates are (I think) independent from releases.
>
>Thoughts?

Sounds all reasonable to me.
Just wanted to state that I'm sorry I can't be involved more these days but 
that I'm happy to see that consistently high level of activity.

Urs

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

2.21.0 and announcements

[David Kastrup]

So it's time to roll out 2.21.0 and I think the build instructions are
ok-ish for that.  We don't clarify the relations/recommendations for
Guile-1.8/2.x but that relation/recommendation is currently in flux and
this is an unstable release.

We still haven't made the "big" 2.20 announcement, and 2.21.0 being out
would make the web page consistent with regard to stable/unstable, so
that would seem like a good opportunity.

Except that the web page currently is broken with some Python2/3
problems, and that people are hitting a roadblock with MacOSX.  I think
we should point out on our download page that the GUB-provided
installers are _only_ for 32bit MacOSX, and that separate downloads may
be provided elsewhere (possibly linking to Marnen's page in the hope
that it does not get overloaded?).

Because once the big announcements are made, we want people to actually
be able to work with what they find on the web page.

We can release 2.21.0 prior to that, of course, since the web page
updates are (I think) independent from releases.

Thoughts?

-- 
David Kastrup

Re: Add dynamic-interface to keepAliveInterfaces (issue 553760043 by j...@abou-samra.fr)

[Werner LEMBERG]

> What I am worried about is a partitura that puts common dynamics on
> every staff, including staves without notes.

Never seen that, AFAIK.  Can you provide a link to such a score?


Werner

Re: Add dynamic-interface to keepAliveInterfaces (issue 553760043 by j...@abou-samra.fr)

[lemzwerg--- via Discussions on LilyPond development]

LGTM


https://codereview.appspot.com/553760043/diff/565830044/Documentation/notation/staff.itely
File Documentation/notation/staff.itely (right):

https://codereview.appspot.com/553760043/diff/565830044/Documentation/notation/staff.itely#newcode801
Documentation/notation/staff.itely:801: rests, skips, or a combination
of these elements. This behavior can be
Please use two spaces after a full stop.

https://codereview.appspot.com/553760043/diff/565830044/Documentation/notation/staff.itely#newcode807
Documentation/notation/staff.itely:807: solely skips will then be
removed.
Maybe s/solely skips/skips only/

https://codereview.appspot.com/553760043/

Re: Patch on dynamics and \RemoveEmptyStaves

[James Lowe]

On 26/03/2020 12:15, David Kastrup wrote:

Jean Abou Samra  writes:


Hi,

Le 24/03/2020 à 23:05, Trevor a écrit :


Hi "Jean Abou Samra", you wrote

My SourceForge username is jean-abou-samra. Could someone please
give me write access to the issue tracker?

Added as a Developer, with Update and Create permissions in addition
to Read.

Welcome aboard!

Trevor

Thank you!

Here is a question about updating patches using git-cl: whenever I try
to upload the patch, I get this error.


IOError: ('http error', 401, 'Unauthorized', )


Traceback attached. What am I doing wrong?

The question is rather what git-cl is doing wrong.  This is some fallout
from SourceForge changes (and/or our move from Google Code to there)
that nobody has gotten around to get fixed yet.


Yes David K is correct. If someone could take a look at the scripts in 
git-cl and get them working smoothly again (there are other errors 
reported on this list about git-cl) it would be a boon to the dev team.



James

Re: Patch on dynamics and \RemoveEmptyStaves

[David Kastrup]

Jean Abou Samra  writes:

> Hi,
>
> Le 24/03/2020 à 23:05, Trevor a écrit :
>
>> Hi "Jean Abou Samra", you wrote
>>> My SourceForge username is jean-abou-samra. Could someone please
>>> give me write access to the issue tracker?
>>
>> Added as a Developer, with Update and Create permissions in addition
>> to Read.
>>
>> Welcome aboard!
>>
>> Trevor
>
> Thank you!
>
> Here is a question about updating patches using git-cl: whenever I try
> to upload the patch, I get this error.
>
>
> IOError: ('http error', 401, 'Unauthorized',  instance at 0x7f8715613370>)
>
>
> Traceback attached. What am I doing wrong?

The question is rather what git-cl is doing wrong.  This is some fallout
from SourceForge changes (and/or our move from Google Code to there)
that nobody has gotten around to get fixed yet.

-- 
David Kastrup

Re: Add dynamic-interface to keepAliveInterfaces (issue 553760043 by j...@abou-samra.fr)

[dak]

What I am worried about is a partitura that puts common dynamics on
every staff, including staves without notes.  That would keep those from
being kept alive.

So the question is whether we should not possibly create a different
keepAliveInterfaces for the Dynamics context?

Opinions?

https://codereview.appspot.com/553760043/

Re: Issue 5862: Prefer astyle 3.1 and update clang-format options (issue 551640043 by nine.fierce.ball...@gmail.com)

[dak]

On 2020/03/26 01:25:57, Dan Eble wrote:
> It's worth emphasizing this: even with these improvements to the
clang-format
> configuration, those who use clang-format will introduce a truckload
of
> differences from the traditional indentation.

Our own fixcc script introduces some modifications to naked Astyle if I
remember correctly.  Is there some reasonable hope that we could boil
down a "common denominator" style where alternately applying clang
formatting and fixcc would end up with a fixed end result rather than
some cycle?  Of course, that state would trivially be reached by one
style doing nothing, or the styles focusing on different problems, but
that would not be useful: we'd want to end up with either style doing as
complete of a job as possible so that people using either will commit
stuff that is mostly fine.

https://codereview.appspot.com/551640043/

Re: Patch on dynamics and \RemoveEmptyStaves

[Jean Abou Samra]

Hi,

Le 24/03/2020 à 23:05, Trevor a écrit :


Hi "Jean Abou Samra", you wrote
My SourceForge username is jean-abou-samra. Could someone please give 
me write access to the issue tracker?


Added as a Developer, with Update and Create permissions in addition 
to Read.


Welcome aboard!

Trevor


Thank you!

Here is a question about updating patches using git-cl: whenever I try 
to upload the patch, I get this error.



IOError: ('http error', 401, 'Unauthorized', instance at 0x7f8715613370>)



Traceback attached. What am I doing wrong?

Best,

Jean Abou Samra

jean@laptop-jean:~/repos/lilypond$ git-cl upload origin/master
 Documentation/notation/staff.itely | 40 
++--
 ly/engraver-init.ly|  1 +
 2 files changed, 35 insertions(+), 6 deletions(-)
This branch is associated with Rietveld issue 553760043. Adding patch to that 
issue.
Message describing this patch set: Add dynamic-interface to keepAliveInterfaces
Upload server: codereview.appspot.com (change with -s/--server)
Your browser has been opened to visit:

https://codereview.appspot.com/get-access-token?port=8001

If your browser is on a different machine then exit and re-run
upload.py with the command-line parameter

  --no_oauth2_webbrowser

Issue updated. URL: http://codereview.appspot.com/553760043
We were not able to associate this patch with a tracker issue.
Please enter a valid tracker issue number
(or enter nothing to create a new issue): 5865
Traceback (most recent call last):
  File "/home/jean/repos/git-cl/git-cl", line 628, in 
sys.exit(main(sys.argv))
  File "/home/jean/repos/git-cl/git-cl", line 622, in main
return func(argv[2:])
  File "/home/jean/repos/git-cl/git-cl", line 341, in CmdUpload
issueId = projecthosting_upload.upload(issue, patchset, subject, desc, 
issueId)
  File "/home/jean/repos/git-cl/projecthosting_upload.py", line 192, in upload
status = patchy.upload(issue, patchset, subject, description, issue_id)
  File "/home/jean/repos/git-cl/projecthosting_upload.py", line 170, in upload
code_review_url)
  File "/home/jean/repos/git-cl/allura_issues.py", line 79, in update_issue
filehandle = urllib.urlopen (allura_api + str(allura_issue_id) + "/save", 
data_encoded)
  File "/usr/lib/python2.7/urllib.py", line 89, in urlopen
return opener.open(url, data)
  File "/usr/lib/python2.7/urllib.py", line 217, in open
return getattr(self, name)(url, data)
  File "/usr/lib/python2.7/urllib.py", line 462, in open_https
data)
  File "/usr/lib/python2.7/urllib.py", line 381, in http_error
result = method(url, fp, errcode, errmsg, headers, data)
  File "/usr/lib/python2.7/urllib.py", line 693, in http_error_401
errcode, errmsg, headers)
  File "/usr/lib/python2.7/urllib.py", line 388, in http_error_default
raise IOError, ('http error', errcode, errmsg, headers)
IOError: ('http error', 401, 'Unauthorized', )

Re: Trim unused toplevel targets. (issue 547810069 by hanw...@gmail.com)

[David Kastrup]

Han-Wen Nienhuys  writes:

> On Wed, Mar 25, 2020 at 4:12 PM David Kastrup  wrote:
>>
>> hanw...@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/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 
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

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

Re: why was this pushed?

[David Kastrup]

Han-Wen Nienhuys  writes:

> On Wed, Mar 25, 2020 at 8:15 PM David Kastrup  wrote:
>> >> We don't push until the status becomes Push.  Countdown is a last
>> >> chance for reviewers to comment.
>> >
>> > Sorry, I saw Valentin had pushed his, so I assumed this was OK.
>>
>> But it was an issue by someone else.  Pushing changes of someone else
>> prematurely when they have not explicitly asked for it bereaves even the
>> original author of the ability to reconsider.
>
> ?
>
> David Grant doesn't have push access; there is no circumstance under
> which he would push this change himself.

That's why I wrote: "when they have not explicitly asked for it".  It is
not only the repository server you can explicitly ask for such actions,
we have responsive humans as well.

Contributors without push access are usually asked for a git-formatted
patch by the Patch meister when he sets the final "push" state on a
patch.  This makes sure that both patch content and commit message
accurately reflect what the contributor intends to end up in the
repository.  Such last-minute polishings are frequent enough that we
don't push Rietveld patches to master but have a separate staging branch
where the final authoritive tests are being performed.

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

Re: Trim unused toplevel targets. (issue 547810069 by hanw...@gmail.com)

[Han-Wen Nienhuys]

On Wed, Mar 25, 2020 at 4:12 PM David Kastrup  wrote:
>
> hanw...@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/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 - hanw...@gmail.com - http://www.xs4all.nl/~hanwen

Re: why was this pushed?

[Han-Wen Nienhuys]

On Wed, Mar 25, 2020 at 8:15 PM David Kastrup  wrote:
> >> We don't push until the status becomes Push.  Countdown is a last
> >> chance for reviewers to comment.
> >
> > Sorry, I saw Valentin had pushed his, so I assumed this was OK.
>
> But it was an issue by someone else.  Pushing changes of someone else
> prematurely when they have not explicitly asked for it bereaves even the
> original author of the ability to reconsider.

?

David Grant doesn't have push access; there is no circumstance under
which he would push this change himself.

-- 
Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen

Re: why was this pushed?

[pkx166h]

Hello

On 25/03/2020 19:15, David Kastrup wrote:

Han-Wen Nienhuys  writes:


On Wed, Mar 25, 2020 at 7:40 PM Carl Sorensen  wrote:

We don't push until the status becomes Push.  Countdown is a last
chance for reviewers to comment.

Sorry, I saw Valentin had pushed his, so I assumed this was OK.

But it was an issue by someone else.  Pushing changes of someone else
prematurely when they have not explicitly asked for it bereaves even the
original author of the ability to reconsider.

It's somewhat different taking that responsibility for changes by
oneself in circumstances warranting expedited action (like when other
important changes depend on it).

But doing so without updating issue status and without giving some
feedback with regard to the reasons for urgency is, if nothing else,
quite impolite towards the people who have to pick up the bits
afterwards and sort them into place.


I am sure Han-Wen's patches are OK (although I don't personally review 
code so other Devs may have wanted to comment), and the one for David 
was also evidently not broken - although there was at least one 
additional change he made (maybe two) as I discovered this while testing 
his 'updated' patch.


If we;re leaving master 'as is', then David will need to figure out the 
difference between what was checked in and his latest set of patches and 
maybe create a new Rietveld?


Or we could just revert the commit

--

Added vowel transitions for lyrics
author    David Stephen Grant 
    Wed, 25 Mar 2020 09:27:43 + (10:27 +0100)
committer    Han-Wen Nienhuys 
    Wed, 25 Mar 2020 09:27:43 + (10:27 +0100)
commit    b7034e683d47b1e9bb11e5464a7e514912a0d9ba

--

and continue as before (David would still need to rebase though).

Let me know and I'll update the Tracker accordingly.

James