Am 13.11.2015 um 10:57 schrieb Davide Liessi: > 2015-11-13 6:02 GMT+01:00 Henning Hraban Ramm <lilypon...@fiee.net>: >> Why not combine the options? Use GitHub as long as it makes sense, but >> always keep a mirror on OLL server. > That's my opinion, too: option a), plus mirroring the repositories at > git.openlilylib.org. > >
It seems discussion settles towards this, so we'll go that route. With regard to mirroring I think I'll do the following (please tell me if someone has a better solution). Create a Git repository on git.openlilylib.org's server (that is, a local repository on the filesystem, not in the server's Gitlab installation and have the Github repository as 'origin'. Add a web hook on the Gitlab repo that triggers a script on the openlilylib.org server. This script will fetch the updates from Github and can optionally perform further tasks, e.g. build openLilyLib documentation and deploy it. As I don't want to require an http server kept running for this task I would try to implement it in a way that the web server (Nginx) calls the script when the Github web hook calls a certain URL. I don't know how to do that yet but I assume it'll work similarly to calling up PHP stuff through fastCGI. ### One other thing to be discussed is the actual naming. As a prerequisite I have significantly cleaned up the namespace below https://github.com/openlilylib so that there are only three repositories left. However, it's not clear how I should proceed now. Currently we have the "openlilylib" repository which actually contains two different things: * the original collection of "snippets" as started by Janek. These are loosely organized and inconsistently documented LilyPond files scattered in a number of directories. * A new, integrated approach for a library infrastructure, to be found in the /ly directory in the repository. This contains a small number of proof-of-concept (but also working) libraries. The new library files are even less documented (only through source comments at the maintainer's discretion) as designing a proper documentation system is one of the most urgent issues that block any further development. What we want to achieve is: * One repository with the core functionality of the new library infrastructure (this contains the "API" against which libraries (or user code) can work that Jan-Peter mentioned) * A number of library repositories. The libraries that exist inside /ly, for example /ly/gridly or /ly/scholarly, will be moved to repositories at this level. However, I'm not sure if we should create an additional organization (e.g. oll-libraries) for that to avoid cluttering the namespace and website dashboard with potentially numerous libraries and other, independent project repos. BTW: This disentangling implies that *anyone* can create a new library for use with openLilyLib and host it *anywhere*. This will be so much better than the current approach of having the libraries maintained *inside* one single repository. * The current repository, maybe renamed. This set-up will have the big advantage that we can keep the existing repository so no user code will break. Whenever something is moved to the new structure we can make the current functions issue a deprecation warning, telling the user where the new functionality should be taken from (I have already done this several times and provided some helper functions). An implication and additional advantage is that we can keep the existing repository as a collection of loosely related code (as Janek intended: a git-managed and lily-version-agnostic LSR) I suggest (and if noone objects will do it) * renaming the "openlilylib" repository to "snippets" -> https://github.com/openlilylib/snippets NOTE: This may require users to adapt their repository set-ups and LilyPond include path settings * creating a new repository https://github.com/openlilylib/oll-core where the stuff from /ly/_internal will be moved (reviewing a number of things along the way) Regaring the location of the individual libraries, what would you consider best: * adding all beside oll-core (keeping the option that anyone creates libraries in their own place) * creating a new openlilylib sibling organization for that purpose * Just have library maintainers maintain their repos in their own namespace (providing a central listing of available libraries in some place, of course) Best Urs
_______________________________________________ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
