[oll-user] OLLib<->LilyPond | Contribution/review

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

Hi,

probably the last of my 'initial' emails.

Another one of Joe's questions/suggestions:
>   -- 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?
Good point. But I don't think we should over-emphasize OLLib's potential 
as a 'staging area' for LilyPond.
I'd rather say that we should have a rather strict policy of including 
only material in OLLib that has got a certain degree of approval. This 
means that we should discuss the point of including any functionality at 
all, and  have a somewhat strict review process before pushing 
contributions to the master branch.
So first we should consider whether a proposed addition makes sense as 
an enhancement of OLLib and already get an idea if we consider it 
appropriate to propagate it for inclusion into LilyPond.
Then we should review patches and discuss them with regards also to 
syntactical consistence with LilyPond's conventions.

AFAIK GitHub supports pull requests from within a repository, and I have 
read about organizations that created their review process around that.

> I think it would be good to have a focus on review, revision and standardization
> with the aim of being a more flexible test-ground for LP proper.  Of course
> there need be no promises, some stuff may always remain outside.  FWIW I think
> your chosen pianoStaff example could probably be revised and generalized
> sufficiently to be useful in LP proper, it's only a matter of time and thought.
>   One possible way would be to replace SUp and SDown meaning, use the staff named
> "up" or "down" with, say, \staffUp and \staffDown meaning, switch to the staff
> that is above/below the current one.  Then you need make no assumptions about
> staff naming.
That's a good idea, and you may have noticed that I started my research 
on this topic.
But (for the sake of having an example) I'd nevertheless keep the SUp 
versions as shorthands in a library, because they would then be 
shorthands for \staffUp \voiceOne etc. (which I wouldn't consider as 
really natural for being included in LilyPond proper).

Best
Urs