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
|
