Re: Run grand-replace to update copyright
You can use a range (‘2008-2010’) instead of listing individual years (‘2008, 2009, 2010’) if and only if: 1) every year in the range, inclusive, really is a “copyrightable” year that would be listed individually; and 2) you make an explicit statement in a README file about this usage. OK. I strongly suggest that we use ranges. I don't get the same impression from that page. It begins by saying You should maintain a proper copyright notice and a license notice in each nontrivial file in the package. Well, looking at Emacs, one of the central FSF projects: They also do a `grand copyright year replacement' once a year (cf. commit 106782 in its bzr repository) in all files which have the FSF copyright notice – using ranges, BTW. Thus I don't see any reason why we shouldn't do that either. My corollary is still that we the copyright conversion script is buggy :-) Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Run grand-replace to update copyright
On Sat, Jan 4, 2014 at 11:09 PM, Werner LEMBERG w...@gnu.org wrote: Looks like a mistake in the conversion script. `2012' should be changed to `2012-2014', of course. The purpose of listing the year is to give an indication of when the copyright will expire. If the last copyrightable change to a document was in 2012, but the notice says 2014, then you're effectively claiming copyright for two years longer than you're actually entitled to. That's why it's not allowed (and invalidates the whole notice). 2012-2014 has the same problem, since it says (incorrectly) that some part of the document will still be under copyright after 2012+N. You've misread, I think: The guide doesn't say `file' but `package'. In general, this means that the copyright of *all* files of the LilyPond package should be updated. It might make sense to update them all if they're all meant to claim copyright on LilyPond as a whole, but I don't think that's the case right now. Some of them list different authors, for example. -- Ben (Sorry about the top posting last time; I wasn't thinking.) ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Run grand-replace to update copyright
Looks like a mistake in the conversion script. `2012' should be changed to `2012-2014', of course. The purpose of listing the year is to give an indication of when the copyright will expire. If the last copyrightable change to a document was in 2012, but the notice says 2014, then you're effectively claiming copyright for two years longer than you're actually entitled to. That's why it's not allowed (and invalidates the whole notice). 2012-2014 has the same problem, since it says (incorrectly) that some part of the document will still be under copyright after 2012+N. AFAIK, this is not correct. We have to make a distinction between singular files and files that a part of a package. What matters for us is the *package* copyright. Theoretically, no files in a package needs a copyright notice at all if there is a central copyright notice – consider some binary stuff where it isn't possible to add a copyright notice at all. As soon as a file becomes part of a package, it inherits the packages copyright. So if just a single file of a package gets changed, the copyright year in the package's copyright notice must be adjusted, and consequently this gets inherited by all files of the package, even if there was no change. You've misread, I think: The guide doesn't say `file' but `package'. In general, this means that the copyright of *all* files of the LilyPond package should be updated. It might make sense to update them all if they're all meant to claim copyright on LilyPond as a whole, but I don't think that's the case right now. Some of them list different authors, for example. Basically, you are right. However, there is a silent agreement that if someone contributes to lilypond, the contribution becomes part of the lilypond package, so the maintainers might adjust the copyright of the package and thus that of individual files. Of course, this doesn't cover the change of the license itself. If this silent agreement gets ever violated, we have to follow standard FSF procedures (since lilypond is an official GNU package), asking all contributors to sign copyright assignments to the FSF, which would be extremely tedious... Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Run grand-replace to update copyright
On Sun, Jan 05, 2014 at 09:37:30AM +0100, Werner LEMBERG wrote: The purpose of listing the year is to give an indication of when the copyright will expire. AFAIK, this is not correct. We have to make a distinction between singular files and files that a part of a package. What matters for us is the *package* copyright. I do not believe that there is a notion of package copyright in most countries' laws. But at this point, I'd like to propose a distinction between (at least) two questions: - does the GNU maintainers' guide make suggestions that are founded in good legal understanding? - does lilypond follow the GNU maintainers' guide? I am reasonably confident that GNU organization consulted with lawyers as necessary to produce a good set of guidelines. Admittely the focus would likely be on US copyright law, but I'm still confident that GNU considered the international situation as well. However, it is always possible that somebody made a mistake, or that the guide is difficult to understand. In such case, I suggest contacting GNU directly. I think the second question is of more immediate concern for lilypond. If we don't follow the legal guidelines proposed by GNU, then we're in a much weaker position if any problems occur. If this silent agreement gets ever violated, we have to follow standard FSF procedures (since lilypond is an official GNU package), asking all contributors to sign copyright assignments to the FSF, which would be extremely tedious... Official GNU packages are not required to sign copyright to the FSF (that's in the guidelines), but they are encouraged to do so. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 3720: Built-in templates for SATB vocal scores (issue 41990043)
On 2014/01/05 01:42:55, dak wrote:
https://codereview.appspot.com/41990043/diff/60001/ly/satb.ly
File ly/satb.ly (right):
https://codereview.appspot.com/41990043/diff/60001/ly/satb.ly#newcode1
ly/satb.ly:1:
Missing \version number is causing an error when running convert-ly.
https://codereview.appspot.com/41990043/diff/60001/ly/satb.ly#newcode68
ly/satb.ly:68: (if (defined? name) name (if (pair? default) (car
default)
'#{#})))
'#{#} is expensive. I'd rather use *unspecified* here.
https://codereview.appspot.com/41990043/diff/60001/ly/satb.ly#newcode70
ly/satb.ly:70: #(define (sym . strings) (string-symbol (apply
string-append
strings)))
For an include file (rather than a module), this and some other macro
names seem
awfully likely to cause collisions.
https://codereview.appspot.com/41990043/diff/60001/ly/satb.ly#newcode84
ly/satb.ly:84: (let ((above (if (pair? optionals) (car optionals)
#f)))
(if x y #f) is easier to understand and write as (and x y), in
particular if x
takes up considerable space.
https://codereview.appspot.com/41990043/diff/60001/ly/satb.ly#newcode93
ly/satb.ly:93: #{#})))
Why #{#} unquoted? That evaluates at macro placement time. But I'd
use
*unspecified* anyway.
https://codereview.appspot.com/41990043/diff/60001/ly/satb.ly#newcode97
ly/satb.ly:97: \new Staff = #(identity ,name) \with {
Why #(identity ,name) here instead of #,name ?
https://codereview.appspot.com/41990043/diff/60001/ly/satb.ly#newcode104
ly/satb.ly:104: \clef #(identity ,clef)
What's with the identity? It does not make sense.
I'll skip the copious other occurences but they should be fixed.
As this patch has already been pushed I'll open a new
tracker to cover these issues.
Trevor
https://codereview.appspot.com/41990043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Run grand-replace to update copyright
AFAIK, this is not correct. We have to make a distinction between singular files and files that a part of a package. What matters for us is the *package* copyright. I do not believe that there is a notion of package copyright in most countries' laws. On page http://www.gnu.org/prep/maintain/html_node/Copyright-Notices.html I see this: To update the list of year numbers, add each year in which you have made nontrivial changes to the package. (Here we assume you’re using a publicly accessible revision control server, so that every revision installed is also immediately and automatically published.) When you add the new year, it is not required to keep track of which files have seen significant changes in the new year and which have not. It is recommended and simpler to add the new year to all files in the package, and be done with it for the rest of the year. This answers it, doesn't it? - does the GNU maintainers' guide make suggestions that are founded in good legal understanding? Definitely yes! The FSF Europe is also working on this. For example, the GPL has successfully defended in German courts. - does lilypond follow the GNU maintainers' guide? I hope so. If we don't, we should access our working routines. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Double G clef, tenor G clef, varpercussion clef and varC clef (issue 47840043)
https://codereview.appspot.com/47840043/diff/20001/mf/feta-clefs.mf File mf/feta-clefs.mf (right): https://codereview.appspot.com/47840043/diff/20001/mf/feta-clefs.mf#newcode186 mf/feta-clefs.mf:186: reduced_ss# = staff_space# * reduction; On 2014/01/05 04:51:22, lemzwerg wrote: Uh, oh, the diff here on Rietveld is so big and unreadable because you've converted tabs to spaces, probably inadvertently. Please post another revision of your patch that fixes this, and ensure that your editor doesn't do this conversion automatically again. I moved the definition of new_bulb to the beginning of the file. Diff seems to try to check differences paragraph-wise (i.e. splitted on empty lines), and this is where this ugly diff result comes from, I assume. The last time I had tab/space conversion problems, the diff looked completely different, so I think this is not the case here. https://codereview.appspot.com/47840043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Double G clef, tenor G clef, varpercussion clef and varC clef (issue 47840043)
Uh, oh, the diff here on Rietveld is so big and unreadable because
converted tabs to spaces, probably inadvertently. [...]
I moved the definition of new_bulb to the beginning of the
file. Diff seems to try to check differences paragraph-wise
(i.e. splitted on empty lines), and this is where this ugly diff
result comes from, I assume.
Not really.
The last time I had tab/space conversion problems, the diff looked
completely different, so I think this is not the case here.
Well, you *should* use tabs, so this deserves a new patch set anyway.
It's easy to see in the web browser:
- after := z2'{dir (turning_dir * 90)}
- .. end_point{dir (end_angle)};
- (u, v) = before intersectiontimes after;
+thin := hround (0.15 reduced_ss);
+thin := hround (3/2 hair);
The `-' and `+' lines are not aligned vertically.
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Fw: Merge conflict
- Original Message - From: Phil Holmes em...@philholmes.net To: Devel lilypond-devel@gnu.org Sent: Sunday, January 05, 2014 12:19 PM Subject: Merge conflict I'm trying to create a 2.19.0 build and running into merge conflicts. Following the CG, I've done: git fetch git checkout release/unstable git merge origin/master This creates a number of merge conflicts: changes.tely is an obvious one. Is there something that can be simply done to sort the conflicts out? -- Phil Holmes Forwarding from a different email address. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Run grand-replace to update copyright
Carl Sorensen carl.d.soren...@gmail.com writes: In response to issue 3765, I ran make grand-replace to update all copyright notices to 2014. It looks like I no longer have push privileges, so I couldn't push the patch to staging. According to Savannah, you still have push privileges (and I should be surprised if not). What did you try? What was the error message? Did you perhaps not use a member checkout? URL:http://savannah.gnu.org/git/?group=lilypond Note that if you a) have a member checkout b) can do anything at all you have push privileges. A revocation of push privileges would mean that your member checkouts would stop working completely. An anonymous checkout will always work, but only for reading. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fw: Merge conflict
Phil Holmes m...@philholmes.net writes: - Original Message - From: Phil Holmes em...@philholmes.net To: Devel lilypond-devel@gnu.org Sent: Sunday, January 05, 2014 12:19 PM Subject: Merge conflict I'm trying to create a 2.19.0 build and running into merge conflicts. Following the CG, I've done: git fetch git checkout release/unstable git merge origin/master This creates a number of merge conflicts: changes.tely is an obvious one. Is there something that can be simply done to sort the conflicts out? -- Phil Holmes Forwarding from a different email address. Well, we released 2.17.97 from the stable branch, but the release process still used release/unstable. It has a number of reverts in it compared to the unstable branch. We don't want _any_ of that in 2.19.0. We basically have two options: a) reset release/unstable and recreate it from scratch b) do a dummy merge that resolves everything in favor of being 2.19.0 The dummy merge will give us sort of a linear history in release/unstable. It will not help much otherwise. It has the advantage that people's own checkouts of release/unstable will not look conflicting. But I think that our continuity requirements for release/unstable are probably not as hard as master. All in all, I think the best compromise is to rewind to the branch-off point, like git fetch git checkout release/unstable git reset --hard origin/release/unstable git merge origin/master However, this would do a fast forward anyway. So I think I'll just bump release/unstable to master. And then you can do git fetch git checkout release/unstable git reset --hard origin/release/unstable git merge origin/master # should be a noop or fast forward and then continue from there. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fw: Merge conflict
- Original Message - From: David Kastrup d...@gnu.org To: Phil Holmes m...@philholmes.net Cc: Devel lilypond-devel@gnu.org Sent: Sunday, January 05, 2014 2:46 PM Subject: Re: Fw: Merge conflict Phil Holmes m...@philholmes.net writes: - Original Message - From: Phil Holmes em...@philholmes.net To: Devel lilypond-devel@gnu.org Sent: Sunday, January 05, 2014 12:19 PM Subject: Merge conflict I'm trying to create a 2.19.0 build and running into merge conflicts. Following the CG, I've done: git fetch git checkout release/unstable git merge origin/master This creates a number of merge conflicts: changes.tely is an obvious one. Is there something that can be simply done to sort the conflicts out? -- Phil Holmes Forwarding from a different email address. Well, we released 2.17.97 from the stable branch, but the release process still used release/unstable. It has a number of reverts in it compared to the unstable branch. We don't want _any_ of that in 2.19.0. We basically have two options: a) reset release/unstable and recreate it from scratch That had been what I thought easiest and most sensible, once I'd spent a bit longer thinking. [snip] So I think I'll just bump release/unstable to master. And then you can do git fetch git checkout release/unstable git reset --hard origin/release/unstable git merge origin/master # should be a noop or fast forward and then continue from there. -- David Kastrup Thanks. Willdo. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Run grand-replace to update copyright
On 1/5/14 12:09 AM, Werner LEMBERG w...@gnu.org wrote: I'm not a lawyer, but the year in a copyright notice is supposed to be the year of original publication. If you have a document first published in 2012 with a Copyright 2012 notice and you change the year to 2014 without making any other changes, [...] Looks like a mistake in the conversion script. `2012' should be changed to `2012-2014', of course. I don't think there is a mistake in the conversion script. I think this was a hypothetical, rather than an actual case where 2012 turned to 2014. grep 2014 0001-Run-grand-replace-issue-3765.patch | grep -v - returned nothing. And we see the following: carl@carl-lilydev ~/lilypond-git (dev/cds)$ grep 2013 0001-Run-grand-replace-issue-3765.patch -Copyright (c) 1996--2013, The LilyPond authors (lilypond.org) - Copyright (C) 2013 Aleksandr Andreev aleksandr.andr...@gmail.com + Copyright (C) 2013--2014 Aleksandr Andreev aleksandr.andr...@gmail.com - Copyright (C) 2013 Mike Solomon m...@mikesolomon.org + Copyright (C) 2013--2014 Mike Solomon m...@mikesolomon.org - Copyright (C) 2013 Aleksandr Andreev aleksandr.andr...@gmail.com + Copyright (C) 2013--2014 Aleksandr Andreev aleksandr.andr...@gmail.com - Copyright (C) 2013 Aleksandr Andreev aleksandr.andr...@gmail.com + Copyright (C) 2013--2014 Aleksandr Andreev aleksandr.andr...@gmail.com - Copyright (C) 2013 by Heikki Tauriainen g034...@welho.com. + Copyright (C) 2013--2014 by Heikki Tauriainen g034...@welho.com. - Copyright (C) 2013 Mike Solomon m...@mikesolomon.org + Copyright (C) 2013--2014 Mike Solomon m...@mikesolomon.org # Walter Garcia-Fontes walter.gar...@upf.edu, 2013. -# Copyright (C) 2013 Han-Wen Nienhuys, Jan Nieuwenhuizen +# Copyright (C) 2013--2014 Han-Wen Nienhuys, Jan Nieuwenhuizen -# Copyright (C) 2013 Free Software Foundation, Inc. +# Copyright (C) 2013--2014 Free Software Foundation, Inc. - Copyright (C) 2013 Mike Solomon m...@mikesolomon.org + Copyright (C) 2013--2014 Mike Solomon m...@mikesolomon.org where 2013 properly changes to 2013--2014. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Run grand-replace to update copyright
I don't think there is a mistake in the conversion script. I think this was a hypothetical, rather than an actual case where 2012 turned to 2014. [...] Very good, thanks for checking. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: License of files in Documentation/pictures and ability to distribute them unclear
Hello, On 05/01/14 03:51, Graham Percival wrote: On Fri, Jan 03, 2014 at 03:28:22PM -0800, Don Armstrong wrote: There are a lot of files in Documentation/pictures which have no clear license, and unfortunately, the git log for them isn't clear at all either. Indeed; those should be clarified. Some of them cannot be distributed by lilypond either, for example, logo-debian.png is the Debian Restricted Use Logo.[1] Oops. Yes, we should replace it with the open use logo. http://www.debian.org/logos/index.en.html http://code.google.com/p/lilypond/issues/detail?id=3779 James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: CG: basic cleanup (issue 46120044)
https://codereview.appspot.com/46120044/diff/1/Documentation/contributor/administration.itexi
File Documentation/contributor/administration.itexi (right):
https://codereview.appspot.com/46120044/diff/1/Documentation/contributor/administration.itexi#newcode219
Documentation/contributor/administration.itexi:219: instructions in the
CG at @ref{Push access}. Do not set
It's not just about pushing. The Savannah terminology on the general
Git pages and the project specific pages is project member access or
member access in contrast to anonymous access.
https://codereview.appspot.com/46120044/diff/1/Documentation/contributor/administration.itexi#newcode1574
Documentation/contributor/administration.itexi:1574: @subsubheading Push
git access
This would seem to warrant changing as well.
https://codereview.appspot.com/46120044/diff/1/Documentation/contributor/source-code.itexi
File Documentation/contributor/source-code.itexi (right):
https://codereview.appspot.com/46120044/diff/1/Documentation/contributor/source-code.itexi#newcode123
Documentation/contributor/source-code.itexi:123: command-line version of
Git 1.7 or higher.}
On 2014/01/01 06:08:09, Graham Percival wrote:
just curious, what changed in git 1.5 vs. 1.7 that's important to
these
instructions?
Possibly the default behavior for
git push
without arguments. Also possible git clone behavior. At any rate,
LilyDev seems to be 1.7, so we probably are not all that informed about
1.5 any more.
https://codereview.appspot.com/46120044/diff/1/Documentation/contributor/source-code.itexi#newcode654
Documentation/contributor/source-code.itexi:654: The branches are kept
for archival reasons.
That's not actually correct. It's more like These branches are for
making stable releases. They are only to be changed by their respective
maintainers.
https://codereview.appspot.com/46120044/diff/1/Documentation/contributor/source-code.itexi#newcode1554
Documentation/contributor/source-code.itexi:1554: @node Push access
Member access.
https://codereview.appspot.com/46120044/diff/1/Documentation/contributor/source-code.itexi#newcode1745
Documentation/contributor/source-code.itexi:1745: git config
push.default matching
That's actually the worst possible setting in my experience since it
tends to push stuff you did not intend to push. The Git documentation
explicitly says this is unsuitable for shared repositories:
· matching - push all branches having the same name in both
ends.
This is for those who prepare all the branches into a
publishable shape and then push them out with a single
command.
It is not appropriate for pushing into a repository
shared by
multiple users, since locally stalled branches will
attempt a
non-fast forward push if other users updated the branch.
This is currently the default, but Git 2.0 will change
the
default to simple.
I think we should rather recommend simple here. It's always possible
to give explicit instructions, so it is not like the user will be
blocked.
upstream has the disadvantage that it will push feature branches
straight to master. So simple is best.
https://codereview.appspot.com/46120044/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Doc: NR Tidy up of Midi 3.5.x sections (issue 47940043)
LGTM (apart from trivial punctuation)
https://codereview.appspot.com/47940043/diff/1/Documentation/notation/input.itely
File Documentation/notation/input.itely (right):
https://codereview.appspot.com/47940043/diff/1/Documentation/notation/input.itely#newcode2749
Documentation/notation/input.itely:2749: @rinternals{Dynamic_performer}
period
https://codereview.appspot.com/47940043/diff/1/Documentation/notation/input.itely#newcode2809
Documentation/notation/input.itely:2809: @rinternals{Dynamic_performer}
period
https://codereview.appspot.com/47940043/diff/1/Documentation/notation/input.itely#newcode2936
Documentation/notation/input.itely:2936: repeats);
we usually use a colon here
https://codereview.appspot.com/47940043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Run grand-replace to update copyright
On 1/5/14 12:00 AM, David Kastrup d...@gnu.org wrote: According to Savannah, you still have push privileges (and I should be surprised if not). What did you try? What was the error message? Did you perhaps not use a member checkout? URL:http://savannah.gnu.org/git/?group=lilypond Yes, that was the problem. On my new VM, I did a git clone from the public address. After updating my ssh keys, and reconfiguring my repository, I can now push to staging. Thanks for pointing me in the right direction! Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
PATCHES: Countdown for January 9th - 06:00
Hello, 3770 http://code.google.com/p/lilypond/issues/detail?id=3770q=label%3APatch-countdown%20OR%20label%3APatch-waiting%20OR%20label%3APatch-review%20OR%20label%3APatch-new%20OR%20label%3APatch-pushsort=patchcolspec=ID%20Type%20Status%20Stars%20Owner%20Patch%20Needs%20Summary%20Modified Enhancement David Kastrup push Patch: Print semantic values for -ddebug-parser in display-lily-music style. 3769 http://code.google.com/p/lilypond/issues/detail?id=3769q=label%3APatch-countdown%20OR%20label%3APatch-waiting%20OR%20label%3APatch-review%20OR%20label%3APatch-new%20OR%20label%3APatch-pushsort=patchcolspec=ID%20Type%20Status%20Stars%20Owner%20Patch%20Needs%20Summary%20Modified Enhancement David Kastrup push Patch: Lexer/Parser: Don't package location data in SCM_TOKEN semantic value 3767 http://code.google.com/p/lilypond/issues/detail?id=3767q=label%3APatch-countdown%20OR%20label%3APatch-waiting%20OR%20label%3APatch-review%20OR%20label%3APatch-new%20OR%20label%3APatch-pushsort=patchcolspec=ID%20Type%20Status%20Stars%20Owner%20Patch%20Needs%20Summary%20Modified Enhancement James Lowe push Change vim plugin from f6 view .ps to .pdf 3764 http://code.google.com/p/lilypond/issues/detail?id=3764q=label%3APatch-countdown%20OR%20label%3APatch-waiting%20OR%20label%3APatch-review%20OR%20label%3APatch-new%20OR%20label%3APatch-pushsort=patchcolspec=ID%20Type%20Status%20Stars%20Owner%20Patch%20Needs%20Summary%20Modified Enhancement Janek Warchol push Patch: Swap 'polite' and 'l2r' variable definitions 3761 http://code.google.com/p/lilypond/issues/detail?id=3761q=label%3APatch-countdown%20OR%20label%3APatch-waiting%20OR%20label%3APatch-review%20OR%20label%3APatch-new%20OR%20label%3APatch-pushsort=patchcolspec=ID%20Type%20Status%20Stars%20Owner%20Patch%20Needs%20Summary%20Modified Enhancement Keith Ohara push LeftEdge no longer takes up space 3753 http://code.google.com/p/lilypond/issues/detail?id=3753q=label%3APatch-countdown%20OR%20label%3APatch-waiting%20OR%20label%3APatch-review%20OR%20label%3APatch-new%20OR%20label%3APatch-pushsort=patchcolspec=ID%20Type%20Status%20Stars%20Owner%20Patch%20Needs%20Summary%20Modified Enhancement Carl Peterson push Patch: Cleanup of ugly MI and SOL shaped noteheads 3751 http://code.google.com/p/lilypond/issues/detail?id=3751q=label%3APatch-countdown%20OR%20label%3APatch-waiting%20OR%20label%3APatch-review%20OR%20label%3APatch-new%20OR%20label%3APatch-pushsort=patchcolspec=ID%20Type%20Status%20Stars%20Owner%20Patch%20Needs%20Summary%20Modified Documentation Trevor Daniels push Issue 2673, Volta improvements, remains essentially undocumented and untested 3745 http://code.google.com/p/lilypond/issues/detail?id=3745q=label%3APatch-countdown%20OR%20label%3APatch-waiting%20OR%20label%3APatch-review%20OR%20label%3APatch-new%20OR%20label%3APatch-pushsort=patchcolspec=ID%20Type%20Status%20Stars%20Owner%20Patch%20Needs%20Summary%20Modified Enhancement Devon Schudy push Patch: Tremolo cleanup. 2594 http://code.google.com/p/lilypond/issues/detail?id=2594q=label%3APatch-countdown%20OR%20label%3APatch-waiting%20OR%20label%3APatch-review%20OR%20label%3APatch-new%20OR%20label%3APatch-pushsort=patchcolspec=ID%20Type%20Status%20Stars%20Owner%20Patch%20Needs%20Summary%20Modified Documentation James Lowe push Documenting hammer-on and pull-off 1999 http://code.google.com/p/lilypond/issues/detail?id=1999q=label%3APatch-countdown%20OR%20label%3APatch-waiting%20OR%20label%3APatch-review%20OR%20label%3APatch-new%20OR%20label%3APatch-pushsort=patchcolspec=ID%20Type%20Status%20Stars%20Owner%20Patch%20Needs%20Summary%20Modified Documentation James Lowe push Nonsensical example in programming-interface.itely 3776 http://code.google.com/p/lilypond/issues/detail?id=3776q=label%3APatch-countdown%20OR%20label%3APatch-waiting%20OR%20label%3APatch-review%20OR%20label%3APatch-new%20OR%20label%3APatch-pushsort=patchcolspec=ID%20Type%20Status%20Stars%20Owner%20Patch%20Needs%20Summary%20Modified Enhancement David Kastrup countdown Patch: Doc: simplify \score description, matching its current syntax 3766 http://code.google.com/p/lilypond/issues/detail?id=3766q=label%3APatch-countdown%20OR%20label%3APatch-waiting%20OR%20label%3APatch-review%20OR%20label%3APatch-new%20OR%20label%3APatch-pushsort=patchcolspec=ID%20Type%20Status%20Stars%20Owner%20Patch%20Needs%20Summary%20Modified Ugly Mike Solomon countdown Accidental clashes with Tuplet Number 3781 http://code.google.com/p/lilypond/issues/detail?id=3781q=label%3APatch-countdown%20OR%20label%3APatch-waiting%20OR%20label%3APatch-review%20OR%20label%3APatch-new%20OR%20label%3APatch-pushsort=patchcolspec=ID%20Type%20Status%20Stars%20Owner%20Patch%20Needs%20Summary%20Modified Enhancement James Lowe review Patch: Doc: NR Tidy up of Midi 3.5.x sections 3780
Re: Doc: NR Tidy up of Midi 3.5.x sections (issue 47940043)
Thanks Trevor.
https://codereview.appspot.com/47940043/diff/1/Documentation/notation/input.itely
File Documentation/notation/input.itely (right):
https://codereview.appspot.com/47940043/diff/1/Documentation/notation/input.itely#newcode2749
Documentation/notation/input.itely:2749: @rinternals{Dynamic_performer}
On 2014/01/05 22:36:36, Trevor Daniels wrote:
period
Done.
https://codereview.appspot.com/47940043/diff/1/Documentation/notation/input.itely#newcode2809
Documentation/notation/input.itely:2809: @rinternals{Dynamic_performer}
On 2014/01/05 22:36:36, Trevor Daniels wrote:
period
Done.
https://codereview.appspot.com/47940043/diff/1/Documentation/notation/input.itely#newcode2936
Documentation/notation/input.itely:2936: repeats);
On 2014/01/05 22:36:36, Trevor Daniels wrote:
we usually use a colon here
Done.
https://codereview.appspot.com/47940043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
