Re: [oll-user] Call for initial feedback

[Janek W. <lem...@gm...>]

2013/3/20 Urs Liska <ul...@op...>

> I think it actually _is_ somewhat confusing, as I've always found that
> somewhat confusing with SourceForge project that I just visited.
> So I'll try to clarify as best as I can:
>
> I have set up three projects on *SourceForge*:
>
>    - *openLilyLib* (http://sourceforge.net/projects/openlilylib/)
>    This contains OLLib (the 'LilyPond library' part) and the tutorials
>    library
>     - *musicexamples* (http://sourceforge.net/projects/musicexamples/)
>    LaTeX package to manage music examples
>     - *lilyglyphs* (http://sourceforge.net/projects/lilyglyphs/)
>    LaTeX package to include notational elements in LaTeX documents
>
> And the website content and other "meta" stuff is in a fourth repository?

I have separated the three parts in separate Git repositories because a) I
> found that development of them is quite separate and b) someone interested
> in cloning one of the parts doesn't have to get everything.
> The downside is that there are dependencies, especially for collaborators
> authoring LaTeX documents: Everyone who wants to compile any of the
> documents with the openLilyLib document class has to have all three
> packages installed.
> So it might be more consistent to have everything in one Git repository
> after all. Then everybody who clones that repository has everything
> available he needs (and only has to configure some paths/symlinks).
> Unfortunately I don't know how to merge Git repositories. I have read a
> few guides on how to do it, but it seems quite non-trivial to preserve the
> history and not to run into path conflicts (commits pointing to wrong file
> locations).
> If that would be possible, we could have one SourceForge project only,
> which would be less confusing probably.
>

I like tinkering with git and i think i could learn how to merge
repositories.  However, maybe git submodules would be a correct answer?  A
submodule is just a repository inside another repository, so that we could
have a big repo containing all projects, while all of them would remain to
be separate repos.
I don't know how well that plays with SourceForge, however.

>
>
> *openLilyLib*, the main project, has the following menu items in addition:
>
>    - *Blog*
>    I'm not sure if we really need one, but SourceForge strongly
>    encourages that in order to expose a project's activity and make it more
>    visible to the SourceForge community
>    - *Tickets*
>    The issue tracking system.
>    It is quite configurable, but I don't have understood it fully yet.
>    Tickets for all part-projects are collected here, with a field to
>    assign the ticket to one of the projects.
>    - *Mailing Lists*
>    Currently there is only this one (openlilylib-user).
>    I'm not sure if we should have separate public and private (-dev)
>    lists, or separate lists for the subprojects. But probably there won't be
>    too much traffic in the foreseeable future anyway, so we might stick with
>    the existing single list.
>    (-> Thoughts and suggestions welcome)
>
> I suggest to stay with one list until we need more of them.

>
>    - *Discussion*
>    Configurable forums.
>    I'm not sure if we need this or should concentrate the communication
>    on the mailing list.
>    The advantage I see with forums is that it significantly reduces the
>    step for externals to actually expose themselves and post something. And it
>    is more likely for interested people to browse a forum than the archives of
>    a mailing list.
>    The disadvantage is that it might be somewhat dissociated to have
>    information partly in forums and a mailing list.
>    (-> Thoughts and suggestions welcome)
>
> I'd concentrate on a mailing list.

> I only use the project web space for openLilyLib and have configured it so
> that the domain www.openlilylib.org points to that project web space.
> So we have a web site with our own domain that is actually hosted at
> SourceForge.
> This web site contains an introduction to the project and an overview of
> the different subprojects.
> For file downloads, tickets and discussion we only link to SourceForge,
> but we provide the current manuals (the 'musicexamples' page is a quite
> good example ATM).
> How this web site will evolve we'll see over the time. It might remain a
> kind of 'business card', a mere entry point to the SourceForge project
> pages. Or it could evolve to something bigger, I have no idea so far.
> However, the tutorials will be presented here, and this will probably the
> most prominent part of the web site, as it will have a larger number of
> pages (one for each tutorial).
>
> ############
>
> So, this was quite lengthy, but I hope i clarifies the context a bit ...
>
yep, thanks!

>     And one of the most important issues is to prepare a first file
> release of OLLib, however incomplete this will be.
> For that we (I) have to fixate the 'entry point' strategy (I will have a
> closer look at how Jan-Peters lalily (https://github.com/jpvoigt/lalily)
> does this and see how I can apply/transfer the concept. Then that first
> stage has to be documented.
> I think it is important to have OLLib as a file release early, even if i
> only contains a small number of functions. But that will enable us to show
> what it actually is (and can become) to attract users, feedback and
> collaborators.
>

+1

best,
Janek
-------------- next part --------------
An HTML attachment was scrubbed...