Re: [oll-user] Call for initial feedback

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

Am 20.03.2013 16:50, schrieb Janek Warchoł:
> 2013/3/20 Urs Liska <ul...@op... <mailto: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?
Ah, sorry.
No, the website content is in a dedicated directory within the 
openLilyLib repository. (you can browse that in the "Code" area of 
openLilyLib, the directory is 'project-web'.
AFAICS one can't use Git to manage the project web space (which is a 
pity if it's true).
So the work-flow is: Make changes to the content (or the templates or 
the css ...), commit and push them to the openLilyLib repo and upload 
them to the web space with rsync.
It's conceptionally a little bit awkward but works quite smoothly.

>
>     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.
Hm, for some reason I don't really know I'm 'scared' by Git submodules.
The documentation on SourceForge doesn't mention submodules, but I don't 
know if there are special needs for that on the server.
I think I will look in the official Git docs and get a better idea what 
submodules really are.
>
>     *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.
That's what  thought (otherwise I'd have created a bunch of them already 
;-) )
>
>       * *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.
Probably more consistent, indeed.

Urs
-------------- next part --------------
An HTML attachment was scrubbed...