GSoC 2020 update: (hopefully) final commits made; testing time

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

GSoC 2020 update: (hopefully) final commits made; testing time

Owen Lamb
Hi all!

First, an apology--I thought the project was due today, the 23rd, but it's
actually due next week, on the 31st. Tomorrow is just the first day I can
submit the project. Well, better to err on the side of caution! I'd like to
finish things up at least three days before the Monday deadline--i.e.
Friday--if possible.

I've reordered and rebased my code, and it is now up to date with the
current master. I've just published the new branch to GitLab as
dev/lamb/GSoC-2020-final if you'd like to give it a look. It's only nine
commits now, instead of over a hundred, and they're ordered in a way that's
hopefully easy to follow.

(I made a few changes to the code as I reordered it--removing the vestiges
of abandoned ideas, backtracking on a few things I'm unsure of, and
ensuring LilyPond compiles correctly at every commit. This means the latest
GSoC-2020-final snapshot doesn't match the latest GSoC-2020 snapshot
exactly.)

I suppose this last week, then, is for testing and docs. I'll figure out
how to run the regtests, ensuring I didn't break anything from commit to
commit, and write new regtests as necessary, involving the new
features, like /smuflglyph.

At the same time, I'll write docs for my work. I figure I'll make nine
documentation commits, one for each code change commit. (Of course, I may
not need one for every commit, but we'll see.) Does that sound all right?
Would it be better to make yet another branch with the documentation
integrated into the main commits?

And, of course, I'll also be working on my blog post, which I've already
started writing! I'll let you guys know when it's finished, which will
hopefully be in a couple days.

Questions, comments, and concerns are welcome as always.

Thanks,
Owen
Reply | Threaded
Open this post in threaded view
|

Re: GSoC 2020 update: (hopefully) final commits made; testing time

Werner LEMBERG

> I've reordered and rebased my code, and it is now up to date with
> the current master.  I've just published the new branch to GitLab as
> dev/lamb/GSoC-2020-final if you'd like to give it a look.  It's only
> nine commits now, instead of over a hundred, and they're ordered in
> a way that's hopefully easy to follow.

Thanks!

> At the same time, I'll write docs for my work.  I figure I'll make
> nine documentation commits, one for each code change commit.  (Of
> course, I may not need one for every commit, but we'll see.)  Does
> that sound all right?  Would it be better to make yet another branch
> with the documentation integrated into the main commits?

I don't see any reason to synchronize the documentation with commits;
it looks like unnecessary work.  Maybe others disagree, but I think
you should simply add all of the documentation in a single, separate
commit.


    Werner

Reply | Threaded
Open this post in threaded view
|

Re: GSoC 2020 update: (hopefully) final commits made; testing time

Urs Liska-3
Am Montag, den 24.08.2020, 09:06 +0200 schrieb Werner LEMBERG:

> > I've reordered and rebased my code, and it is now up to date with
> > the current master.  I've just published the new branch to GitLab
> as
> > dev/lamb/GSoC-2020-final if you'd like to give it a look.  It's
> only
> > nine commits now, instead of over a hundred, and they're ordered in
> > a way that's hopefully easy to follow.
>
> Thanks!
>
> > At the same time, I'll write docs for my work.  I figure I'll make
> > nine documentation commits, one for each code change commit.  (Of
> > course, I may not need one for every commit, but we'll see.)  Does
> > that sound all right?  Would it be better to make yet another
> branch
> > with the documentation integrated into the main commits?
>
> I don't see any reason to synchronize the documentation with commits;
> it looks like unnecessary work.  Maybe others disagree, but I think
> you should simply add all of the documentation in a single, separate
> commit.
>

+1

But probably regtests should match the state of their commits. Except
if you can add all regtests at the end.

Urs
>
>     Werner
>


Reply | Threaded
Open this post in threaded view
|

Re: GSoC 2020 update: (hopefully) final commits made; testing time

Werner LEMBERG
In reply to this post by Werner LEMBERG

>> At the same time, I'll write docs for my work.  I figure I'll make
>> nine documentation commits, one for each code change commit.

Hmm.  Maybe I've misunderstood you.  What's actually missing are
documentation strings *within* the commits.  For example, the commit

  Add smufl data to feta glyphs & METAFONT logs

lacks any further description.

In other words, I see a necessity that you amend all of your commits,
enriching each of them with detailed documentation that enables a
reader to understand what's really going on, then doing a force-push
of your branch.

This doesn't replace real user documentation, of course, which should
be added, too.


    Werner

Reply | Threaded
Open this post in threaded view
|

Re: GSoC 2020 update: (hopefully) final commits made; testing time

Werner LEMBERG
In reply to this post by Owen Lamb

> I've reordered and rebased my code, and it is now up to date with
> the current master. I've just published the new branch to GitLab as
> dev/lamb/GSoC-2020-final if you'd like to give it a look. It's only
> nine commits now, instead of over a hundred, and they're ordered in
> a way that's hopefully easy to follow.

Some more comments.

* Who has written the file `glyphnames.json`?  It lacks a copyright
  header.  If this is a non-lilypond file copied verbatim, please add
  a separate file (say, `glyphnames.json.txt`) that gives all the
  details: author, origin, license, retrieving date, etc.  If
  necessary, a comment should be added to LilyPond's `LICENSE` file.

* You also have to mention the non-LilyPond JSON file license in the
  `LICENSE` file since it is not GPL.

* In general, all new files like `scm/name-conversion.scm` need a
  copyright header similar to other files.  Exception are very small,
  auxiliary files with, say, less then 10 (not too long) lines of
  data.


    Werner

Reply | Threaded
Open this post in threaded view
|

Re: GSoC 2020 update: (hopefully) final commits made; testing time

Owen Lamb
On Mon, Aug 24, 2020 at 1:07 AM Werner LEMBERG <[hidden email]> wrote:

> * Who has written the file `glyphnames.json`?  It lacks a copyright
>   header.  If this is a non-lilypond file copied verbatim, please add
>   a separate file (say, `glyphnames.json.txt`) that gives all the
>   details: author, origin, license, retrieving date, etc.  If
>   necessary, a comment should be added to LilyPond's `LICENSE` file.


So, glyphnames.json.txt would look like this?

glyphnames.json, created by Daniel Spreadbury, was retrieved from
https://github.com/w3c/smufl on DD Mon YYYY. It is licensed under the
W3C Community Contributor License Agreement and the W3C Final
Specification Agreement.

It seems that the SMuFL specification (including its helper files) are
under two licenses which complement each other, the W3C Community
Contributor License Agreement and the W3C Final Specification Agreement. I
don't quite understand their relationship to each other, though. Does only
one need to be mentioned, or both?


> * You also have to mention the non-LilyPond JSON file license in the
>   `LICENSE` file since it is not GPL.
>

All right. Should I also include a copy of the license(s) in the same
manner as LICENSE.OFL and LICENSE.DOCUMENTATION?

* In general, all new files like `scm/name-conversion.scm` need a
>   copyright header similar to other files.  Exception are very small,
>   auxiliary files with, say, less then 10 (not too long) lines of
>   data.
>

Gotcha. Currently, scm/name-conversion.scm and scm/smufl-map.scm are
generated by gen-emmentaler.fontforge.py. I take it, then, that that script
should also generate the headers?

Thanks,
Owen
Reply | Threaded
Open this post in threaded view
|

Re: GSoC 2020 update: (hopefully) final commits made; testing time

Werner LEMBERG

> So, glyphnames.json.txt would look like this?
>
>   glyphnames.json, created by Daniel Spreadbury, was retrieved from
>   https://github.com/w3c/smufl on DD Mon YYYY. It is licensed under
>   the W3C Community Contributor License Agreement and the W3C Final
>   Specification Agreement.

Looks good, yes.

> It seems that the SMuFL specification (including its helper files)
> are under two licenses which complement each other, the W3C
> Community Contributor License Agreement and the W3C Final
> Specification Agreement.  I don't quite understand their
> relationship to each other, though.  Does only one need to be
> mentioned, or both?

You should mention whatever is mentioned for SMuFL.

>> * You also have to mention the non-LilyPond JSON file license in the
>>   `LICENSE` file since it is not GPL.
>
> All right. Should I also include a copy of the license(s) in the
> same manner as LICENSE.OFL and LICENSE.DOCUMENTATION?

No.  A link is sufficient, I think.

> Currently, scm/name-conversion.scm and scm/smufl-map.scm are
> generated by gen-emmentaler.fontforge.py. I take it, then, that that
> script should also generate the headers?

Ideally yes.  In particular it should have something like

  THIS IS A GENERATED FILE.  DO NOT EDIT!

  Creator: gen-emmentaler.fontforge.ly

  ...


    Werner

Reply | Threaded
Open this post in threaded view
|

Re: GSoC 2020 update: (hopefully) final commits made; testing time

Owen Lamb
On Sat, Aug 29, 2020 at 3:09 AM Werner LEMBERG <[hidden email]> wrote:

>
> > So, glyphnames.json.txt would look like this?
> >
> >   glyphnames.json, created by Daniel Spreadbury, was retrieved from
> >   https://github.com/w3c/smufl on DD Mon YYYY. It is licensed under
> >   the W3C Community Contributor License Agreement and the W3C Final
> >   Specification Agreement.
>
> Looks good, yes.
>

A couple more things. While it does appear likely--based on git
history--that Daniel Spreadbury created this particular file, he has not
placed a particular copyright on it. The specification as a whole, on the
other hand, is copyright "the Contributors to the Standard Music Font
Layout Specification" (see
https://w3c.github.io/smufl/gitbook/preamble/license.html).

On top of that, the W3C Final Specification Agreement (FSA) at
https://www.w3.org/community/about/process/final/, section 2, seems to say
that an author attribution is unnecessary, only requiring we mention the
standard's name and version (i.e. Standard Music Font Layout version 1.3).
My legalese isn't that great, though, so I'd appreciate a second pair of
eyes to make sure.

> It seems that the SMuFL specification (including its helper files)
> > are under two licenses which complement each other, the W3C
> > Community Contributor License Agreement and the W3C Final
> > Specification Agreement.  I don't quite understand their
> > relationship to each other, though.  Does only one need to be
> > mentioned, or both?
>
> You should mention whatever is mentioned for SMuFL.
>

Ah! I looked more closely and it looks like the current version is only
under the W3C Final Specification Agreement. Sorry for the bother.

Here's another stab at glyphnames.json.txt, given all this new information:

glyphnames.json is a part of the Standard Music Font Layout (SMuFL)
specification, version 1.3. It was retrieved from
https://github.com/w3c/smufl on 29 Aug 2020, and is licensed under the
W3C Final Specification Agreement, found at
https://www.w3.org/community/about/process/final/.

What do you think?
Reply | Threaded
Open this post in threaded view
|

Re: GSoC 2020 update: (hopefully) final commits made; testing time

Werner LEMBERG
 
> Here's another stab at glyphnames.json.txt, given all this new information:
>
>   glyphnames.json is a part of the Standard Music Font Layout
>   (SMuFL) specification, version 1.3.  It was retrieved from
>   https://github.com/w3c/smufl on 29 Aug 2020, and is licensed under
>   the W3C Final Specification Agreement, found at
>   https://www.w3.org/community/about/process/final/.
>
> What do you think?

Again, this looks fine :-)


    Werner