Re: [oll-user] Call for initial feedback

[Urs L. <ul...@op...>]

Hi Joe,

thanks for that detailed feedback.

Am 28.03.2013 13:49, schrieb Joseph Rushton Wakeling:
> On 03/18/2013 01:06 PM, Urs Liska wrote:
>> I have completed a first working version of our site www.openlilylib.org
>> and would like to ask you for feedback before I proceed.
> These are still somewhat superficial impressions as I have not had a lot of
> brain time free due to work :-(  But here goes:
>
>    -- I would like to see a better clarification of the relationship between
>       OLLib and Lilypond proper.  In particular where usability/technical
>       tools are provided, why aren't they being pushed directly into LP proper?
>       Will they be in future?  How is the development relationship seen for the
>       future, e.g. will OLLib be for LP something like what Boost is for C++, a
>       testing and review ground where concepts and tools can be refined before
>       being standardized?
To be clear (maybe I suspect some misunderstanding here): OLLib is a 
'pure' LilyPond library. The user will write \include "OLLib.ily" (after 
making the path accessible) and then can access all the function and 
commands we provide in there. In addition he may include units from the 
OLLincludes subdirectory (e.g. engravers) or he may inspect and use 
material from the OLLexamples and OLLtemplates directories.
Functions we implement here _may_ be added in the future to LilyPond, if 
we and the LilyPond developers consider them general and important (and 
stable) enough. In the past we developed the \shape function in our 
library, before David N managed to get it in the main code base.

OTOH there are functions that just aren't general enough to be part of 
LilyPond.
Take /OLLib/toolboxes/pianoToolbox/pianoStaff.ily for example (one of 
the few items already online). These shorthands are very useful for 
switching staves in piano music, but they rely on a certain naming 
convention for the staves ("up" and "down"). This naming convention is 
consistent with the score blocks in OLLincludes and _can_ of course be 
apllied without these includes. But I couldn't imagine having a command 
in LilyPond that only works if you name the staves in a specific way.
So this kind of content is an optional enhancement that will never be 
part of LilyPond itself.

>    -- In respect of the above, how is the rationale different between the toolbox
>       and the documentation?
I'm not really sure if I understand you correctly. Maybe it's more to 
the point to ask about the relation between OLLib documentation and 
tutorials?
There will be one 'book' documenting OLLib. This is traditional 
documentation.
And there will be tutorials that are made accessible on the web site. 
They aren't conceptually related to OLLib, although they may of course 
use it and may dwell on certain aspects of it.

Is that clearer?
>    -- I think it's worth separating out the toolbox and documentation aspects of
>       OLLib into separate projects.  Or rather: I would separate tools and their
>       immediate documentation, from larger-scale tutorials and manuals.
Hm, I'd say that's the plan already?
We have three 'tools': OLLib (plus ...includes and examples), 
musicexamples, lilyglyphs. Each one of them has its own individual manual.
Beside that there are  the collection of tutorials, and a Contributor's 
Guide.
> Separate
>       "books" and tutorials should probably be separate Git branches, which
>       might be grouped together using submodules.
Hm, I don't like having that stuff in separate branches. Of course 
commits will probably never interfere because we have independent 
directories. But that necessarily means that whenever I check out a 
branch to work on one book, the others are removed from the working tree 
and I can't have a look at them.
>
>       Example reason: suppose you have some tutorials which contain in-copyright
>       material, and a downstream user wants to easily excise them.  It's MUCH
>       easier if they can simply delete a pointer to a submodule, rather than
>       having to inherit a complete project history including the copyrighted
>       material.
>
>       That could also be a protection for OLLib itself, because in the event of
>       a publisher dispute we could just remove the individual git repo of the
>       disputed material, rather than having to do messy rewrites of a large
>       amount of git history.
That may be a valid point, but I think we shouldn't have any 
compromising material in it from the start.
>
>    -- Bear in mind that separating as much as possible into separate repos or
>       branches is also good because many git commands scale with overall project
>       size, hence grouping projects into modules as small as possible helps
>       improve the developer experience and the ability of the project to expand.
I can't really judge that due to lack of experience. I'm constantly 
struggling with keeping all my repos up to date (as I work on different 
computers I usually have to go through that procedure at lease four 
times a day ...), which is even more tedious if I rebase my 'private' 
branches and have to take great care to incorporate them correctly in 
the other local repo(s).

>
>    -- What's the status of lilyglyphs on CTAN?  Would be good to get it there
>       quickly and add a link accordingly.
>
>    -- Ditto musicexamples.
There is _no_ status yet for both because I have no idea about the 
proceedings. I planned to look into this as soon as there are regular 
file releases for both packages.
The 0.2 release of 'musicexamples' isn't available ATM, and I will have 
to change that release once more before making it available again, 
because I have changed the copyright notice (in the hope there won't be 
somebody who downloaded it in the few days and will make a problem out 
of it.)
Probably that would be a candidate for a separate thread (if it still 
has to be discussed), but I think we should license all source code 
(i.e. LilyPond sources and LaTeX packages) with the GPL and the 
'creative' parts (documentation and tutorials) with CC BY-SA.

Best
Urs
>
> ------------------------------------------------------------------------------
> Own the Future-Intel® Level Up Game Demo Contest 2013
> Rise to greatness in Intel's independent game demo contest.
> Compete for recognition, cash, and the chance to get your game
> on Steam. $5K grand prize plus 10 genre and skill prizes.
> Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d
> _______________________________________________
> openlilylib-user mailing list
> ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openlilylib-user