Am 13.11.2015 um 10:57 schrieb Davide Liessi:
2015-11-13 6:02 GMT+01:00 Henning Hraban Ramm<address@hidden>:
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
address@hidden
https://lists.gnu.org/mailman/listinfo/lilypond-user