lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Web: Review GSoC page introduction (issue 315410043 by address@hidde


From: git
Subject: Re: Web: Review GSoC page introduction (issue 315410043 by address@hidden)
Date: Mon, 30 Jan 2017 08:17:01 -0800


https://codereview.appspot.com/315410043/diff/40001/Documentation/web/community.itexi
File Documentation/web/community.itexi (right):

https://codereview.appspot.com/315410043/diff/40001/Documentation/web/community.itexi#newcode952
Documentation/web/community.itexi:952: @subheading Adopt the SMuFL music
font encoding standard
On 2017/01/30 15:08:45, dak wrote:
Uh, that's not exactly what I would call "fixing embarrassing syntax
errors".
It is a complete new paragraph.

Though it's not clear to me how this diff comes about: this appears to
be
already in LilyPond proper anyway.

I'm not sure what you're concretely referring to here.
In the line the link pointed to (comparing base to patch set 3 There
isn't anything in the diff.

You will see that SMuFL project paragraph as new when you compare Patch
set 2 with patch set 3. This is due to the fact that patch set 2 was
uploaded before I could push #5037.

Before uploading patch set 3 I rebased my branch on master to make sure
that a) it still merges and b) that what's in the patch set is what will
eventually be applied to master. Should I *not* do that and keep my
branch untouched until the last moment (i.e. before pushing)? But what
happens when master moves further in the meantime? This is not unlikely,
since I'm going to have a number of patches about the projects on this
page.

Of course I can see now that you don't have a reference to what the
current patch set is actually doing, OK, that's not very nice.
But you can probably ignore that one in this case if the patch passes
make doc. Then you can just read it as-is.

https://codereview.appspot.com/315410043/



reply via email to

[Prev in Thread] Current Thread [Next in Thread]