openlilylib-user

[oll-user] Call for initial feedback

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

Hi all,

I have completed a first working version of our site www.openlilylib.org 
and would like to ask you for feedback before I proceed.
My next steps would be to personally invite a selection of people to 
participate in the project and after that send an email to lilypond-user 
presenting the project and ask for collaboration.

The next major task (maybe this should be before the 'public' email) 
would probably be to provide regular file releases for all subprojects, 
although some of them are in a really pre-release state.

If you are interested in the functionality of the 'content management' 
in use you may go to
http://sourceforge.net/p/openlilylib/code/ci/40851d534239654dd10165e6fec51046aa3f3f5d/tree/project-web/
and browse the 'content' folder. Each subfolder represents a page 
(numbered pages go into the automatic navigation, unnumbered pages are 
'floating'), and you can select the template to be used by the filename 
(for now there is only one template, therefore all content files are 
named '1-col.txt'). The content of the files are to be entered in a 
(IMHO quite sympathical) mixture of Markdown and HTML. Basically one can 
use markdown to format the content, but you can simply enter any HTML if 
that isn't enough (for example to use named classes).
The css structure isn't really developed yet but a rather 
straightforward use of what the YAML framework already provides, with 
some small adjustments.

Best
Urs

Re: [oll-user] Call for initial feedback

[Joseph R. W. <jos...@we...>]

Hi Urs,

Sorry for radio silence in these last couple of weeks.  Will have feedback for
you soon. :-)

Best wishes,

    -- Joe

Re: [oll-user] Call for initial feedback

[Wim v. D. <ma...@wi...>]

A good initiative. I will certainly try to follow it, although I can't  
predict now how much time and energy I will have in the near future to  
contribute.

Regards,
Wim.




On 18 Mar 2013, at 13:06 , Urs Liska wrote:

> Hi all,
>
> I have completed a first working version of our site www.openlilylib.org
> and would like to ask you for feedback before I proceed.
> My next steps would be to personally invite a selection of people to
> participate in the project and after that send an email to lilypond- 
> user
> presenting the project and ask for collaboration.
>
> The next major task (maybe this should be before the 'public' email)
> would probably be to provide regular file releases for all  
> subprojects,
> although some of them are in a really pre-release state.
>
> If you are interested in the functionality of the 'content management'
> in use you may go to
> http://sourceforge.net/p/openlilylib/code/ci/40851d534239654dd10165e6fec51046aa3f3f5d/tree/project-web/
> and browse the 'content' folder. Each subfolder represents a page
> (numbered pages go into the automatic navigation, unnumbered pages are
> 'floating'), and you can select the template to be used by the  
> filename
> (for now there is only one template, therefore all content files are
> named '1-col.txt'). The content of the files are to be entered in a
> (IMHO quite sympathical) mixture of Markdown and HTML. Basically one  
> can
> use markdown to format the content, but you can simply enter any  
> HTML if
> that isn't enough (for example to use named classes).
> The css structure isn't really developed yet but a rather
> straightforward use of what the YAML framework already provides, with
> some small adjustments.
>
> Best
> Urs
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_mar
> _______________________________________________
> openlilylib-user mailing list
> ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openlilylib-user

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

Re: [oll-user] Call for initial feedback

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

Hi Urs,

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

> Hi all,
>
> I have completed a first working version of our site www.openlilylib.org
> and would like to ask you for feedback before I proceed.
>

Congratulations!
I have to admit i'm a bit confused as to what goes where: are the parts
(OLL, lilyglyphs, ...) each in a separate git repository; what's the
connection between sourceforge and openlilylib.org (what can be found
where).
But maybe i just need to use it for some time.


> My next steps would be to personally invite a selection of people to
> participate in the project and after that send an email to lilypond-user
> presenting the project and ask for collaboration.
>

+1

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

Re: [oll-user] Call for initial feedback

[Jan-Peter V. <jp....@gm...>]

Hi Urs,

this looks really nice - I like it!
I didn't know about stacey ... I will have a deeper look :)
Shall I delete the google group, we introduced earlier? We don't need 
it, if this is working in sourceforge.

Best
Jan-Peter


Am 18.03.2013 13:06, schrieb Urs Liska:
> Hi all,
>
> I have completed a first working version of our site www.openlilylib.org
> and would like to ask you for feedback before I proceed.
> My next steps would be to personally invite a selection of people to
> participate in the project and after that send an email to lilypond-user
> presenting the project and ask for collaboration.
>
> The next major task (maybe this should be before the 'public' email)
> would probably be to provide regular file releases for all subprojects,
> although some of them are in a really pre-release state.
>
> If you are interested in the functionality of the 'content management'
> in use you may go to
> http://sourceforge.net/p/openlilylib/code/ci/40851d534239654dd10165e6fec51046aa3f3f5d/tree/project-web/
> and browse the 'content' folder. Each subfolder represents a page
> (numbered pages go into the automatic navigation, unnumbered pages are
> 'floating'), and you can select the template to be used by the filename
> (for now there is only one template, therefore all content files are
> named '1-col.txt'). The content of the files are to be entered in a
> (IMHO quite sympathical) mixture of Markdown and HTML. Basically one can
> use markdown to format the content, but you can simply enter any HTML if
> that isn't enough (for example to use named classes).
> The css structure isn't really developed yet but a rather
> straightforward use of what the YAML framework already provides, with
> some small adjustments.
>
> Best
> Urs
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_mar
> _______________________________________________
> openlilylib-user mailing list
> ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openlilylib-user

Re: [oll-user] Call for initial feedback

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

Am 20.03.2013 13:34, schrieb Jan-Peter Voigt:
> Hi Urs,
>
> this looks really nice - I like it!
> I didn't know about stacey ... I will have a deeper look :)
Yes, makes a very good impression for small scaled web sites.
Although I have already run into the first issues that I'll have to see 
if they can be solved ...
> Shall I delete the google group, we introduced earlier? We don't need
> it, if this is working in sourceforge.
Yes, please. The openlilylib-user mailing list is the replacement for 
the Google group.

Best
Urs
>
> Best
> Jan-Peter
>
>
> Am 18.03.2013 13:06, schrieb Urs Liska:
>> Hi all,
>>
>> I have completed a first working version of our site www.openlilylib.org
>> and would like to ask you for feedback before I proceed.
>> My next steps would be to personally invite a selection of people to
>> participate in the project and after that send an email to lilypond-user
>> presenting the project and ask for collaboration.
>>
>> The next major task (maybe this should be before the 'public' email)
>> would probably be to provide regular file releases for all subprojects,
>> although some of them are in a really pre-release state.
>>
>> If you are interested in the functionality of the 'content management'
>> in use you may go to
>> http://sourceforge.net/p/openlilylib/code/ci/40851d534239654dd10165e6fec51046aa3f3f5d/tree/project-web/
>> and browse the 'content' folder. Each subfolder represents a page
>> (numbered pages go into the automatic navigation, unnumbered pages are
>> 'floating'), and you can select the template to be used by the filename
>> (for now there is only one template, therefore all content files are
>> named '1-col.txt'). The content of the files are to be entered in a
>> (IMHO quite sympathical) mixture of Markdown and HTML. Basically one can
>> use markdown to format the content, but you can simply enter any HTML if
>> that isn't enough (for example to use named classes).
>> The css structure isn't really developed yet but a rather
>> straightforward use of what the YAML framework already provides, with
>> some small adjustments.
>>
>> Best
>> Urs
>>
>> ------------------------------------------------------------------------------
>> Everyone hates slow websites. So do we.
>> Make your web apps faster with AppDynamics
>> Download AppDynamics Lite for free today:
>> http://p.sf.net/sfu/appdyn_d2d_mar
>> _______________________________________________
>> openlilylib-user mailing list
>> ope...@li...
>> https://lists.sourceforge.net/lists/listinfo/openlilylib-user
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_mar
> _______________________________________________
> openlilylib-user mailing list
> ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openlilylib-user

Re: [oll-user] Call for initial feedback

[Jan-Peter V. <jp....@gm...>]

Am 20.03.2013 13:35, schrieb Urs Liska:
> Am 20.03.2013 13:34, schrieb Jan-Peter Voigt:
>
>> Shall I delete the google group, we introduced earlier? We don't need
>> it, if this is working in sourceforge.
> Yes, please. The openlilylib-user mailing list is the replacement for
> the Google group.
OK, done

Re: [oll-user] Call for initial feedback

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

Am 20.03.2013 12:41, schrieb Janek Warchoł:
> Hi Urs,
>
> 2013/3/18 Urs Liska <ul...@op... <mailto:ul...@op...>>
>
>     Hi all,
>
>     I have completed a first working version of our site
>     www.openlilylib.org <http://www.openlilylib.org>
>     and would like to ask you for feedback before I proceed.
>
>
> Congratulations!
> I have to admit i'm a bit confused as to what goes where:
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

Initially I had set up the second and third project as 'subprojects' to 
the first one, but that didn't really work - I have the impression this 
is quite buggy on SourceForge's part.
Actually I didn't even seem to succeed deleting these subprojects, so 
they are still there in the main navigation of the openLilyLib project.

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.

######################

Each of the current projects has the following menu items on its project 
page:

  * *Summary*
    Overview, Screenshots, Features
    -> SourceForge's entry page for any project
  * *Files*
    Download area (although only 'musicexamples' has a file release here
    so far)
  * *Reviews* (automatic and not influencable)
    Structure for user reviews
  * *Support* (automatic)
    (Details below)
  * *Code*
    Access to the Git repository

*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)
  * *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)

*musicexamples* and *lilyglyphs* only have:

  * *Wiki* (with only one page)
    This states the relation between the (sub) project and the whole
    family and provides links to the relevant information.
    Maybe I should also add such a single Wiki page to openLilyLib?

#######################

Any SourceForge project has a *Project Web* space that can be populated 
individually through file upload. Until now they offered "Hosted Apps", 
a selection of Wiki or CMS application, but that is right now being 
discontinued.

I use "stacey", a tiny PHP framework, to manage the content in this web 
space.
Content can be edited in text files, using Markdown for formatting, HTML 
if that isn't sufficient, and some variables that are implemented 
through stacey.

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 ...

> are the parts (OLL, lilyglyphs, ...) each in a separate git 
> repository; what's the connection between sourceforge and 
> openlilylib.org <http://openlilylib.org> (what can be found where).
> But maybe i just need to use it for some time.
>
>     My next steps would be to personally invite a selection of people to
>     participate in the project and after that send an email to
>     lilypond-user
>     presenting the project and ask for collaboration.
>
>
> +1
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.

Best
Urs
>
> best,
> Janek

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

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...

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...

Re: [oll-user] Call for initial feedback

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

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

> 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.
>

ah, ok.

> 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.
>

I have a bit of experience with them and they seem to be pretty
straightforward.  I was even able to debug a corrupted git repository which
contained a submodule, as you can see here:
http://stackoverflow.com/questions/14797978/git-recovery-object-file-is-empty-how-to-recreate-trees
(that was really awesome!  I felt like a pro when i had finished ;-) )

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

Re: [oll-user] Call for initial feedback

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

On Wed, 20 Mar 2013 17:11:53 +0100
Janek Warchoł <lem...@gm...> wrote:

> 2013/3/20 Urs Liska <ul...@op...>
> 
> 
> > 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.
> >
> 
> I have a bit of experience with them and they seem to be pretty
> straightforward.  I was even able to debug a corrupted git repository which
> contained a submodule, as you can see here:
> http://stackoverflow.com/questions/14797978/git-recovery-object-file-is-empty-how-to-recreate-trees
> (that was really awesome!  I felt like a pro when i had finished ;-) )
:-)

I have just read the submodules chapter in the progit book, and it seems it isn't the best solution.
First, a submodule is a repository with a different remote (i.e. pull in another repository to use and manage it within the main repository). So we'd have to keep the other remote repositories anyway (IIUC). Second, the book issues some warnings about having to be careful not to break things when working in submodules.

For my taste this rather looks like keeping the structure as it is or managing to merge the repositories and maintain them as one.

Best
Urs

> 
> best,
> Janek

Re: [oll-user] Call for initial feedback

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

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

> I have just read the submodules chapter in the progit book, and it seems
> it isn't the best solution.
> First, a submodule is a repository with a different remote (i.e. pull in
> another repository to use and manage it within the main repository). So
> we'd have to keep the other remote repositories anyway (IIUC). Second, the
> book issues some warnings about having to be careful not to break things
> when working in submodules.
>
> For my taste this rather looks like keeping the structure as it is or
> managing to merge the repositories and maintain them as one.
>

You are probably quite right.  I hope to try merging some repos, maybe on
Easter.

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

Re: [oll-user] Call for initial feedback

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

Am 21.03.2013 12:53, schrieb Janek Warchoł:
> 2013/3/21 Urs Liska <ul...@op... <mailto:ul...@op...>>
>
>     I have just read the submodules chapter in the progit book, and it
>     seems it isn't the best solution.
>     First, a submodule is a repository with a different remote (i.e.
>     pull in another repository to use and manage it within the main
>     repository). So we'd have to keep the other remote repositories
>     anyway (IIUC). Second, the book issues some warnings about having
>     to be careful not to break things when working in submodules.
>
>     For my taste this rather looks like keeping the structure as it is
>     or managing to merge the repositories and maintain them as one.
>
>
> You are probably quite right.  I hope to try merging some repos, maybe 
> on Easter.
>
> best,
> Janek
Maybe I succeeded already (although it was at the cost of some nerves 
and an aching back ;-) )
Submodules and subtree merge aren't intended for our purpose, but 
http://saintgimp.org/2013/01/22/merging-two-git-repositories-into-one-repository-without-losing-file-history/ 
helped.

It was quite complex because it is difficult to move content around when 
there is more than one branch. And I ran into trouble (probably) because 
the history wasn't really straightforward (I had moved folders several 
times and once factored a complete folder out into another repo (i.e. 
deleted it from Git's perspective).

But I think I have managed to set up a new, merged repository.
It is here: https://sourceforge.net/p/openlilylib/mergerepos/
and I have uploaded a tar.gz: 
https://dl.dropbox.com/u/49478835/ollMerged.tar.gz
It would be nice if you (Janek) could have a glance at that and its 
history, just to see if it looks reasonable to you).

AFAICS it is a working repository, although history isn't all too nice 
(e.g. in such a combined repo I would prefix each commit message with a 
label (like oll, xmp) which I obviously haven't done in the past).
Now I'll have to bring the directory structure in line again, update 
some readme files and do clean-up stuff like that. But that should be a 
breeze now ...
And finally I'll replace the existing repo so we'll only have one repo.

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

Re: [oll-user] Call for initial feedback

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

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

> Maybe I succeeded already (although it was at the cost of some nerves and
> an aching back ;-) )
> Submodules and subtree merge aren't intended for our purpose, but
> http://saintgimp.org/2013/01/22/merging-two-git-repositories-into-one-repository-without-losing-file-history/helped.
>
> It was quite complex because it is difficult to move content around when
> there is more than one branch. And I ran into trouble (probably) because
> the history wasn't really straightforward (I had moved folders several
> times and once factored a complete folder out into another repo (i.e.
> deleted it from Git's perspective).
>
> But I think I have managed to set up a new, merged repository.
>

Congrats!


>  It is here: https://sourceforge.net/p/openlilylib/mergerepos/
> and I have uploaded a tar.gz:
> https://dl.dropbox.com/u/49478835/ollMerged.tar.gz
> It would be nice if you (Janek) could have a glance at that and its
> history, just to see if it looks reasonable to you).
>

I've looked and i don't see anything wrong.  Looks like a clean job!


>  AFAICS it is a working repository, although history isn't all too nice
> (e.g. in such a combined repo I would prefix each commit message with a
> label (like oll, xmp) which I obviously haven't done in the past).
>

You should be able to do this now using git filter-branch (of course this
will change history, but maybe it's worth it).  Some info for example here:
http://mm0hai.net/blog/2011/03/10/rewriting-git-commit-message-history.html

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

Re: [oll-user] Call for initial feedback

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

Am 21.03.2013 22:46, schrieb Janek Warchoł:
>
>
>
> 2013/3/21 Urs Liska <ul...@op... <mailto:ul...@op...>>
>
>     ...
>
>     But I think I have managed to set up a new, merged repository.
>
>
> Congrats!
>
>     It is here: https://sourceforge.net/p/openlilylib/mergerepos/
>     and I have uploaded a tar.gz:
>     https://dl.dropbox.com/u/49478835/ollMerged.tar.gz
>     It would be nice if you (Janek) could have a glance at that and
>     its history, just to see if it looks reasonable to you).
>
>
> I've looked and i don't see anything wrong.  Looks like a clean job!
Well, it wasn't really.
I was quite irritated that checking out the lgFindstale branch let 
disappear quite a lot of folders (fortunately this doesn't actually 
shock me anymore because I trust that checking out another branch will 
bring me my folders back).
After some thinking I realized the cause for that (well, actually I woke 
up with that thought ;-) ): I had first imported the lilyglyphs repo (to 
which lgFindstale belongs) and then the musicexamples repo. Therefore 
the lgFindstale branch didn't include the commits introducing the 
musicexamples files.
So actually it was all solved with

git checkout lgFindstale
git rebase master

Even without any rebase conflicts.
Now it seems OK and nearly ready to replace the original repository.
>
>     AFAICS it is a working repository, although history isn't all too
>     nice (e.g. in such a combined repo I would prefix each commit
>     message with a label (like oll, xmp) which I obviously haven't
>     done in the past).
>
>
> You should be able to do this now using git filter-branch (of course 
> this will change history, but maybe it's worth it).  Some info for 
> example here:
> http://mm0hai.net/blog/2011/03/10/rewriting-git-commit-message-history.html
I'll look into that (and read the "rewriting history" chapter of the 
main book). History rewriting is surely not an issue in this case, as I 
think I can assume the repository sort of private, I can't imagine 
anybody actually has based some work on it yet).
And if I can manage to make the history look cleaner (as a kind of 
initial state) I'd appreciate it - but only if that doesn't mean I have 
to inspect the 536 commits individually ;-)

Best
Urs
>
> best,
> janek

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

Re: [oll-user] Call for initial feedback

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

Am 22.03.2013 11:23, schrieb Urs Liska:
> ...
>>      AFAICS it is a working repository, although history isn't all too
>>      nice (e.g. in such a combined repo I would prefix each commit
>>      message with a label (like oll, xmp) which I obviously haven't
>>      done in the past).
>>
>>
>> You should be able to do this now using git filter-branch (of course
>> this will change history, but maybe it's worth it).  Some info for
>> example here:
>> http://mm0hai.net/blog/2011/03/10/rewriting-git-commit-message-history.html
> I'll look into that (and read the "rewriting history" chapter of the
> main book). History rewriting is surely not an issue in this case, as I
> think I can assume the repository sort of private, I can't imagine
> anybody actually has based some work on it yet).
> And if I can manage to make the history look cleaner (as a kind of
> initial state) I'd appreciate it - but only if that doesn't mean I have
> to inspect the 536 commits individually ;-)
Hm, having read the link you provided, "Rewriting History" from ProGit 
and the manual entry for git-filter-branch
I still don't see at all how I could proceed to clean up the history.
Any filter-branch approach would only make sense if I could somehow 
reword the commit message automatically - and I don't see how that 
should be possible.
What probably would be necessary would be a complete interactive rebase 
- which isn't a nice perspective with that number of commits.

On the other hand, I'm quite tempted to redesign the history from 
scratch because it is really quite messy IMO (partly because of the fact 
that it's a merged history (there are three 'initial commits' for 
example) and partly because of me only learning all this stuff. And if I 
did that it would probably reduce the number of commits through numerous 
squashes anyway.
What I would like to have (after reading several documents with 
work-flow suggestions) would be:
- a master branch which only has 'stable' commits, e.g. one commit for 
each tag,
- a develop branch which also only has stable commits, but more, i.e. 
one commit for each completed feature branch, sth like

master
   develop
*    release OLLib v0.2
|\
| * oll: add \displayControlPoints
| * oll: add someFeature
* |  release Tutorial Gervasoni
|\
| * tut: finish tutorial Gervasoni
| * xmp: fix #11 - odd/even-sided examples
| * tut:


###########
One day later:
###########

Yesterday I started such a redesign (after making a copy with git clone 
of course - I have put quite some effort in the existing state, and I 
won't start the merge from the beginning again ...).
And it seems to work basically, but (and that's a big but) it seems to 
mean that I have to effectively review each single commit, and the 
perspective is quite discouraging.
If you want to have a look at the current state, you may go to 
http://sourceforge.net/p/openlilylib/rebase-repo/ and browse commits 
there or clone into it.
Branches master and develop are the ones I have created from scratch, 
oldmaster is what the name suggests ;-) and the other branches are 
temporary ones that I use(d) to rip partial branches off oldmaster.
The relation of master and develop is how I intended it (although the 
SourceForge graph displays the chronological relation differently), but 
develop isn't as clean as I would have liked it. Probably it is possible 
to make that better, but either with unreasonable effort or by loosing 
too much detail in the history. Basically develop contains way too many 
intermediate commits that should have been made in feature branches and 
squashed before merging back to develop.
I _could_ proceed that way, but I have the impression this would take me 
about a week, and I'm not sure if that's worth it. Although I assume 
(hope) this repo will live for years ...
Beside the problem of sheer amount of time I have more disturbing 
problems when I encounter rebase conflicts, because I actually don't 
really know if I make damages when resolving them manually - because I 
now don't know anymore which of the conflicting versions is 'better' and 
especially the one leading to the final state. I don't want to think 
about the option that I introduce changes that pass through all later 
merges but cause the final result to be different from what it should be ...


To make that perfectly clear: I DON'T EXPECT ANYBODY TO GO INTO THAT IN 
DETAIL because I know this might take some time. I'd be happy about any 
assistance, but I'm ready to find my way through it on my own.

Maybe a few final questions that can be answered with a plain opinion 
statement:

  * If you look at the history in
    http://sourceforge.net/p/openlilylib/rebase-repo/commit_browser (the
    upper part down to the first "initial commit"), would you think
    that's good design? Or could I go this way but squash the commits in
    'develop' more radically, i.e. leaving only commits like 'add
    commands', 'update manual' or 'fix several bugs'
  * Or if you look at the history in
    http://sourceforge.net/p/openlilylib/mergerepos/commit_browser (the
    state after merging the repos: Would it be acceptable (i.e. the
    better way because it is considerably easier) to leave that history
    as it is (towards the end it is quite linear actually) and only
    start to adhere to the strategy described above from now on. I.e.
    consider the history up to now as the somewhat messy and voluminous
    'initial state'?


Best
Urs

> Best
> Urs
>> best,
>> janek
> -------------- next part --------------
> An HTML attachment was scrubbed...
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_mar
> _______________________________________________
> openlilylib-user mailing list
> ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openlilylib-user

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

Re: [oll-user] Call for initial feedback

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

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

> On the other hand, I'm quite tempted to redesign the history from
> scratch because it is really quite messy IMO (partly because of the fact
> that it's a merged history (there are three 'initial commits' for
> example) and partly because of me only learning all this stuff. And if I
> did that it would probably reduce the number of commits through numerous
> squashes anyway.
>

I know that temptation.
https://github.com/janek-warchol/eja-mater-demonstration is an example of
possible results.  Was it worth it?  Well, only if it'll be used for
analyzing LilyPond performance (another Report article maybe) and/or
demonstrating lily+git workflow to potential "employers".


> What I would like to have (after reading several documents with
> work-flow suggestions) would be:
> - a master branch which only has 'stable' commits, e.g. one commit for
> each tag,
> - a develop branch which also only has stable commits, but more, i.e.
> one commit for each completed feature branch, sth like
>
> master
>    develop
> *    release OLLib v0.2
> |\
> | * oll: add \displayControlPoints
> | * oll: add someFeature
> * |  release Tutorial Gervasoni
> |\
> | * tut: finish tutorial Gervasoni
> | * xmp: fix #11 - odd/even-sided examples
> | * tut:
>

looks nice.


> ###########
> One day later:
> ###########
>
> Yesterday I started such a redesign (after making a copy with git clone
> of course - I have put quite some effort in the existing state, and I
> won't start the merge from the beginning again ...).
> And it seems to work basically, but (and that's a big but) it seems to
> mean that I have to effectively review each single commit, and the
> perspective is quite discouraging.
> If you want to have a look at the current state, you may go to
> http://sourceforge.net/p/openlilylib/rebase-repo/ and browse commits
> there or clone into it.
>

I get a 404 error "We're sorry but we weren't able to process this request"


> I _could_ proceed that way, but I have the impression this would take me
> about a week, and I'm not sure if that's worth it. Although I assume
> (hope) this repo will live for years ...
>

I don't know if it's not too late for such advice, but i'd advise not to do
this.  I think that most projects have a messy history at the beginning,
and anyway if everything will be ok we hope that browsing very old history
won't be necessary.

>
> Maybe a few final questions that can be answered with a plain opinion
> statement:
>
>   * If you look at the history in
>     http://sourceforge.net/p/openlilylib/rebase-repo/commit_browser (the
>     upper part down to the first "initial commit"), would you think
>     that's good design? Or could I go this way but squash the commits in
>     'develop' more radically, i.e. leaving only commits like 'add
>     commands', 'update manual' or 'fix several bugs'
>   * Or if you look at the history in
>     http://sourceforge.net/p/openlilylib/mergerepos/commit_browser (the
>     state after merging the repos: Would it be acceptable (i.e. the
>     better way because it is considerably easier) to leave that history
>     as it is (towards the end it is quite linear actually) and only
>     start to adhere to the strategy described above from now on. I.e.
>     consider the history up to now as the somewhat messy and voluminous
>     'initial state'?
>

These two also return 404 errors, so i assume i'm too late.  Sorry :(
Janek
-------------- next part --------------
An HTML attachment was scrubbed...

Re: [oll-user] Call for initial feedback

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

On Mon, 25 Mar 2013 17:59:04 +0100
Janek Warchoł <lem...@gm...> wrote:

> 2013/3/23 Urs Liska <ul...@op...>
> 
> > On the other hand, I'm quite tempted to redesign the history from
> > scratch because it is really quite messy IMO (partly because of the fact
> > that it's a merged history (there are three 'initial commits' for
> > example) and partly because of me only learning all this stuff. And if I
> > did that it would probably reduce the number of commits through numerous
> > squashes anyway.
> >
> 
> I know that temptation.
> https://github.com/janek-warchol/eja-mater-demonstration is an example of
> possible results.  Was it worth it?  Well, only if it'll be used for
> analyzing LilyPond performance (another Report article maybe) and/or
> demonstrating lily+git workflow to potential "employers".
I have done that now for a feature branch that I boiled down from 9 unordered to 5 tidy commits. I think that's worth it, to tidy up a feature branch before merging into master (or 'develop'), but not for a whole repository.


> ...
>
> These two also return 404 errors, so i assume i'm too late.  Sorry :(
No problem, I think I'm fine with this issue :-)

> Janek

Re: [oll-user] Call for initial feedback

[Joseph R. W. <jos...@we...>]

On 03/20/2013 04:50 PM, Janek Warchoł wrote:
>> 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.

Sorry to come to this late in the day, but I don't see the point in having
one-repo-to-rule-them-all _unless_ done via submodules -- the separation into 3
different projects is quite correct IMO, as each part is clearly independently
useful (or at least, such dependencies as exist are one-way only).

If you want a nice example of submodules, you can see it here with LDC (a
compiler for the D programming language based on the LLVM backend).  This
project has the language runtime, standard library (Phobos) and test suite each
as separate submodules.
https://github.com/ldc-developers/ldc

Since OLL is moving back to GitHub, that shouldn't be a problem.

Re: [oll-user] Call for initial feedback

[Joseph R. W. <jos...@we...>]

On 03/18/2013 01:06 PM, Urs Liska wrote:
> I have completed a first working version of our site www.openlilylib.org 
> and would like to ask you for feedback before I proceed.

These are still somewhat superficial impressions as I have not had a lot of
brain time free due to work :-(  But here goes:

  -- 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?

  -- In respect of the above, how is the rationale different between the toolbox
     and the documentation?

  -- I think it's worth separating out the toolbox and documentation aspects of
     OLLib into separate projects.  Or rather: I would separate tools and their
     immediate documentation, from larger-scale tutorials and manuals.  Separate
     "books" and tutorials should probably be separate Git branches, which
     might be grouped together using submodules.

     Example reason: suppose you have some tutorials which contain in-copyright
     material, and a downstream user wants to easily excise them.  It's MUCH
     easier if they can simply delete a pointer to a submodule, rather than
     having to inherit a complete project history including the copyrighted
     material.

     That could also be a protection for OLLib itself, because in the event of
     a publisher dispute we could just remove the individual git repo of the
     disputed material, rather than having to do messy rewrites of a large
     amount of git history.

  -- Bear in mind that separating as much as possible into separate repos or
     branches is also good because many git commands scale with overall project
     size, hence grouping projects into modules as small as possible helps
     improve the developer experience and the ability of the project to expand.

  -- What's the status of lilyglyphs on CTAN?  Would be good to get it there
     quickly and add a link accordingly.

  -- Ditto musicexamples.

Re: [oll-user] Call for initial feedback

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

Hi Joe,

thanks for that detailed feedback.

Am 28.03.2013 13:49, schrieb Joseph Rushton Wakeling:
> On 03/18/2013 01:06 PM, Urs Liska wrote:
>> I have completed a first working version of our site www.openlilylib.org
>> and would like to ask you for feedback before I proceed.
> These are still somewhat superficial impressions as I have not had a lot of
> brain time free due to work :-(  But here goes:
>
>    -- 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?
To be clear (maybe I suspect some misunderstanding here): OLLib is a 
'pure' LilyPond library. The user will write \include "OLLib.ily" (after 
making the path accessible) and then can access all the function and 
commands we provide in there. In addition he may include units from the 
OLLincludes subdirectory (e.g. engravers) or he may inspect and use 
material from the OLLexamples and OLLtemplates directories.
Functions we implement here _may_ be added in the future to LilyPond, if 
we and the LilyPond developers consider them general and important (and 
stable) enough. In the past we developed the \shape function in our 
library, before David N managed to get it in the main code base.

OTOH there are functions that just aren't general enough to be part of 
LilyPond.
Take /OLLib/toolboxes/pianoToolbox/pianoStaff.ily for example (one of 
the few items already online). These shorthands are very useful for 
switching staves in piano music, but they rely on a certain naming 
convention for the staves ("up" and "down"). This naming convention is 
consistent with the score blocks in OLLincludes and _can_ of course be 
apllied without these includes. But I couldn't imagine having a command 
in LilyPond that only works if you name the staves in a specific way.
So this kind of content is an optional enhancement that will never be 
part of LilyPond itself.

>    -- In respect of the above, how is the rationale different between the toolbox
>       and the documentation?
I'm not really sure if I understand you correctly. Maybe it's more to 
the point to ask about the relation between OLLib documentation and 
tutorials?
There will be one 'book' documenting OLLib. This is traditional 
documentation.
And there will be tutorials that are made accessible on the web site. 
They aren't conceptually related to OLLib, although they may of course 
use it and may dwell on certain aspects of it.

Is that clearer?
>    -- I think it's worth separating out the toolbox and documentation aspects of
>       OLLib into separate projects.  Or rather: I would separate tools and their
>       immediate documentation, from larger-scale tutorials and manuals.
Hm, I'd say that's the plan already?
We have three 'tools': OLLib (plus ...includes and examples), 
musicexamples, lilyglyphs. Each one of them has its own individual manual.
Beside that there are  the collection of tutorials, and a Contributor's 
Guide.
> Separate
>       "books" and tutorials should probably be separate Git branches, which
>       might be grouped together using submodules.
Hm, I don't like having that stuff in separate branches. Of course 
commits will probably never interfere because we have independent 
directories. But that necessarily means that whenever I check out a 
branch to work on one book, the others are removed from the working tree 
and I can't have a look at them.
>
>       Example reason: suppose you have some tutorials which contain in-copyright
>       material, and a downstream user wants to easily excise them.  It's MUCH
>       easier if they can simply delete a pointer to a submodule, rather than
>       having to inherit a complete project history including the copyrighted
>       material.
>
>       That could also be a protection for OLLib itself, because in the event of
>       a publisher dispute we could just remove the individual git repo of the
>       disputed material, rather than having to do messy rewrites of a large
>       amount of git history.
That may be a valid point, but I think we shouldn't have any 
compromising material in it from the start.
>
>    -- Bear in mind that separating as much as possible into separate repos or
>       branches is also good because many git commands scale with overall project
>       size, hence grouping projects into modules as small as possible helps
>       improve the developer experience and the ability of the project to expand.
I can't really judge that due to lack of experience. I'm constantly 
struggling with keeping all my repos up to date (as I work on different 
computers I usually have to go through that procedure at lease four 
times a day ...), which is even more tedious if I rebase my 'private' 
branches and have to take great care to incorporate them correctly in 
the other local repo(s).

>
>    -- What's the status of lilyglyphs on CTAN?  Would be good to get it there
>       quickly and add a link accordingly.
>
>    -- Ditto musicexamples.
There is _no_ status yet for both because I have no idea about the 
proceedings. I planned to look into this as soon as there are regular 
file releases for both packages.
The 0.2 release of 'musicexamples' isn't available ATM, and I will have 
to change that release once more before making it available again, 
because I have changed the copyright notice (in the hope there won't be 
somebody who downloaded it in the few days and will make a problem out 
of it.)
Probably that would be a candidate for a separate thread (if it still 
has to be discussed), but I think we should license all source code 
(i.e. LilyPond sources and LaTeX packages) with the GPL and the 
'creative' parts (documentation and tutorials) with CC BY-SA.

Best
Urs
>
> ------------------------------------------------------------------------------
> Own the Future-Intel® Level Up Game Demo Contest 2013
> Rise to greatness in Intel's independent game demo contest.
> Compete for recognition, cash, and the chance to get your game
> on Steam. $5K grand prize plus 10 genre and skill prizes.
> Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d
> _______________________________________________
> openlilylib-user mailing list
> ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openlilylib-user

Re: [oll-user] Call for initial feedback

[Joseph R. W. <jos...@we...>]

On 03/28/2013 02:56 PM, Urs Liska wrote:
> To be clear (maybe I suspect some misunderstanding here): OLLib is a 
> 'pure' LilyPond library. The user will write \include "OLLib.ily" (after 
> making the path accessible) and then can access all the function and 
> commands we provide in there. 

Just as a small note, I'd recommend only allowing lowercase directory and file
names.  This reflects typical practice for development and libraries across just
about every programming and/or markup language I've ever dealt with and also
helps to avoid potential issues with different case sensitivity rules across OS's.

> In addition he may include units from the 
> OLLincludes subdirectory (e.g. engravers) or he may inspect and use 
> material from the OLLexamples and OLLtemplates directories.

I recommend trying to modularize as much as possible so that users can \include
the minimally necessary parts of OLLib.  Boost is a good example here.

> Functions we implement here _may_ be added in the future to LilyPond, if 
> we and the LilyPond developers consider them general and important (and 
> stable) enough. In the past we developed the \shape function in our 
> library, before David N managed to get it in the main code base.

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.

Looking into that code, I realized there is another issue.  Your stated licence
is GPL.  How is that meant to interact with the case where e.g. I write an
original piece of music and use OLLib's toolbox in my Lilypond source file?  I
am reasonably sure that if I release only the resulting PDF, there would not be
an issue, but if I want to distribute the .ly source file(s) then almost
certainly GPL requirements would kick in and would therefore force me to give a
GPL licence to my piece of music.

This seems to me to be unacceptable overreach on the part of the licensing.  It
may be worth raising this on the LP lists as it probably also applies to LP
\include's.

> I'm not really sure if I understand you correctly. Maybe it's more to 
> the point to ask about the relation between OLLib documentation and 
> tutorials?

Well, I think it's worth mapping out very clearly what kinds of documentation
are envisioned and how they interrelate -- and modularizing appropriately.  For
example, tutorials should probably not be bundled with library documentation.

> There will be one 'book' documenting OLLib. This is traditional 
> documentation.
> And there will be tutorials that are made accessible on the web site. 
> They aren't conceptually related to OLLib, although they may of course 
> use it and may dwell on certain aspects of it.
> 
> Is that clearer?

It's clearer but I also think you have alternatives that are worth considering.
 Consider e.g. how D documents its standard library:
http://dlang.org/phobos/

Each function/data structure in the library has a brief piece of documentation,
including examples, that is closely coupled to the source code (in fact it is
written in the source code next to the code it documents, and the documentation
is automatically collated from these doc entries in a manner similar to Doxygen).

This is nice and easy to maintain because it is trivial to make sure the small
amount of documentation associated with a given function is up to date with the
function implementation itself.

It's imperfect in another way, because it gives you a only case-by-case
documentation that is not so well integrated as (say) a book.  But it also means
you have a fundamental resource to point people towards which is fairly well
guaranteed to be accurate.

That in turn gives you a certain amount of freedom with respect to other more
"user-friendly" documentation such as an in-depth manual or tutorials, because
there's slightly less urgency behind their being 100% up to date and accurate --
they can be _a_ reference, not THE reference

> Hm, I don't like having that stuff in separate branches. Of course 
> commits will probably never interfere because we have independent 
> directories. But that necessarily means that whenever I check out a 
> branch to work on one book, the others are removed from the working tree 
> and I can't have a look at them.

Treat them as separate Git projects which can be submodules of a "master"
project, not as different branches within the same repo.

That way, you can keep as many or as few of them checked out as you want (in
different subdirs), but their version history will be sufficiently independent
that if I want to contribute to just one of them, I can pull that alone and not
have to branch the whole collection.

> That may be a valid point, but I think we shouldn't have any 
> compromising material in it from the start.

Agree, but I think that we have to consider that this is an accident that is
waiting to happen, however careful we are.

> I can't really judge that due to lack of experience. I'm constantly 
> struggling with keeping all my repos up to date (as I work on different 
> computers I usually have to go through that procedure at lease four 
> times a day ...), which is even more tedious if I rebase my 'private' 
> branches and have to take great care to incorporate them correctly in 
> the other local repo(s).

Use rebase with great, great care ;-)

I have to say I have never had that great a problem keeping my repos clean and
up to date, although I have the bonus of using only a single machine most of the
time.  It helps to be very strict with yourself about using feature branches and
maintaining "master" as a clone of upstream.  (Or alternatively, maintaining an
"upstream" branch to same effect.)

Perhaps one of these days we could have a phone/Skype/other VoIP call to discuss
good git practices, and see if we can resolve some of these issues and concerns
together?

> There is _no_ status yet for both because I have no idea about the 
> proceedings. I planned to look into this as soon as there are regular 
> file releases for both packages.
> The 0.2 release of 'musicexamples' isn't available ATM, and I will have 
> to change that release once more before making it available again, 
> because I have changed the copyright notice (in the hope there won't be 
> somebody who downloaded it in the few days and will make a problem out 
> of it.)
> Probably that would be a candidate for a separate thread (if it still 
> has to be discussed), but I think we should license all source code 
> (i.e. LilyPond sources and LaTeX packages) with the GPL and the 
> 'creative' parts (documentation and tutorials) with CC BY-SA.

Licensing needs extremely careful thought, because the bottom line of it is
this: you want to be absolutely, absolutely certain of what derivative work you
are staking a copyleft claim for.  I imagine we both agree that it's important
that software and documentation deriving from your work should continue to be
free-as-in-freedom, and equally that music written using your tools should be
licensable as the composer/publisher/engraver wishes (and that would include .ly
files as well as the graphical score produced).  As things stand I have some
severe doubts that raw GPL/CC-BY-SA would satisfy this requirement.

One way to bypass that issue might be to use a permissive licence for code
and/or documentation, such as the Boost or Apache licenses (for code) and CC-BY
for docs.  It carries a certain risk, but you have to ask how seriously likely
it is that someone would produce a proprietary derivative work in the first
place, and how much damage it would actually do if they did.

This MUST have been discussed with respect to Lilypond \include calls, so let's
examine the past mailing list discussions and also raise the issue on -devel.

Re: [oll-user] Call for initial feedback

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

Am 28.03.2013 17:07, schrieb Joseph Rushton Wakeling:
> On 03/28/2013 02:56 PM, Urs Liska wrote:
>> To be clear (maybe I suspect some misunderstanding here): OLLib is a
>> 'pure' LilyPond library. The user will write \include "OLLib.ily" (after
>> making the path accessible) and then can access all the function and
>> commands we provide in there.
> Just as a small note, I'd recommend only allowing lowercase directory and file
> names.  This reflects typical practice for development and libraries across just
> about every programming and/or markup language I've ever dealt with and also
> helps to avoid potential issues with different case sensitivity rules across OS's.
OK, I'll do that and make it a test case of my branching strategy ;-)
>
>> In addition he may include units from the
>> OLLincludes subdirectory (e.g. engravers) or he may inspect and use
>> material from the OLLexamples and OLLtemplates directories.
> I recommend trying to modularize as much as possible so that users can \include
> the minimally necessary parts of OLLib.  Boost is a good example here.
Hm, that's what I originally intended (and what is actually still there: 
each toolbox folder that actually has content has a ...toolbox.ily file 
that can be included separately).
But Jan-Peter (and to some extent Janek) seemed to prefer an approach 
where the user simply includes the library as a whole.

As we're not fixed yet about the primary entry point strategy we can 
still discuss this (but in a separate thread please. And maybe later - 
maybe we should invite a few more people explicitely to participate in 
the current set of discussion items?
>
>> Functions we implement here _may_ be added in the future to LilyPond, if
>> we and the LilyPond developers consider them general and important (and
>> stable) enough. In the past we developed the \shape function in our
>> library, before David N managed to get it in the main code base.
> 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 (the general one), but it also needs some more 
thoughts (see my previous comment)
>
> Looking into that code, I realized there is another issue.  Your stated licence
> is GPL.  How is that meant to interact with the case where e.g. I write an
> original piece of music and use OLLib's toolbox in my Lilypond source file?  I
> am reasonably sure that if I release only the resulting PDF, there would not be
> an issue, but if I want to distribute the .ly source file(s) then almost
> certainly GPL requirements would kick in and would therefore force me to give a
> GPL licence to my piece of music.
>
> This seems to me to be unacceptable overreach on the part of the licensing.  It
> may be worth raising this on the LP lists as it probably also applies to LP
> \include's.
_If_ that's the case that's in fact inacceptable.
Looks like the perspective to another long running thread on 
lilypond-user ...
>
>> I'm not really sure if I understand you correctly. Maybe it's more to
>> the point to ask about the relation between OLLib documentation and
>> tutorials?
> Well, I think it's worth mapping out very clearly what kinds of documentation
> are envisioned and how they interrelate -- and modularizing appropriately.  For
> example, tutorials should probably not be bundled with library documentation.
Definitely.
>
>> There will be one 'book' documenting OLLib. This is traditional
>> documentation.
>> And there will be tutorials that are made accessible on the web site.
>> They aren't conceptually related to OLLib, although they may of course
>> use it and may dwell on certain aspects of it.
>>
>> Is that clearer?
> It's clearer but I also think you have alternatives that are worth considering.
>   Consider e.g. how D documents its standard library:
> http://dlang.org/phobos/
>
> Each function/data structure in the library has a brief piece of documentation,
> including examples, that is closely coupled to the source code (in fact it is
> written in the source code next to the code it documents, and the documentation
> is automatically collated from these doc entries in a manner similar to Doxygen).
>
> This is nice and easy to maintain because it is trivial to make sure the small
> amount of documentation associated with a given function is up to date with the
> function implementation itself.
>
> It's imperfect in another way, because it gives you a only case-by-case
> documentation that is not so well integrated as (say) a book.  But it also means
> you have a fundamental resource to point people towards which is fairly well
> guaranteed to be accurate.
>
> That in turn gives you a certain amount of freedom with respect to other more
> "user-friendly" documentation such as an in-depth manual or tutorials, because
> there's slightly less urgency behind their being 100% up to date and accurate --
> they can be _a_ reference, not THE reference
Good to think about that.
It was the explicit intention to have more than a reference manual for 
OLLib. The manual should also be a learning resource goint into some 
detail about the underlying concepts.
But of course it is a valid point that this raises the step for someone 
to contribute, say, a single engraver. And of course your considerations 
about the accuracy of the docs is a valid point.

One more item to discuss ...
>
>> Hm, I don't like having that stuff in separate branches. Of course
>> commits will probably never interfere because we have independent
>> directories. But that necessarily means that whenever I check out a
>> branch to work on one book, the others are removed from the working tree
>> and I can't have a look at them.
> Treat them as separate Git projects which can be submodules of a "master"
> project, not as different branches within the same repo.
>
> That way, you can keep as many or as few of them checked out as you want (in
> different subdirs), but their version history will be sufficiently independent
> that if I want to contribute to just one of them, I can pull that alone and not
> have to branch the whole collection.
>
>> That may be a valid point, but I think we shouldn't have any
>> compromising material in it from the start.
> Agree, but I think that we have to consider that this is an accident that is
> waiting to happen, however careful we are.
Right :(
>
>> I can't really judge that due to lack of experience. I'm constantly
>> struggling with keeping all my repos up to date (as I work on different
>> computers I usually have to go through that procedure at lease four
>> times a day ...), which is even more tedious if I rebase my 'private'
>> branches and have to take great care to incorporate them correctly in
>> the other local repo(s).
> Use rebase with great, great care ;-)
Of course, I know.
But as I have to push often and at times that are imposed on me by the 
clock and not by the state of my work (each time I leave a computer), I 
have lots of Work-in-progress commits in my feature branches that I can 
safely rebase. It's just that one has to be careful about them.
And of course I wouldn't rebase a master branch  ;-)
>
> I have to say I have never had that great a problem keeping my repos clean and
> up to date, although I have the bonus of using only a single machine most of the
> time.  It helps to be very strict with yourself about using feature branches and
> maintaining "master" as a clone of upstream.  (Or alternatively, maintaining an
> "upstream" branch to same effect.)
>
> Perhaps one of these days we could have a phone/Skype/other VoIP call to discuss
> good git practices, and see if we can resolve some of these issues and concerns
> together?
Maybe a good idea.
But perhaps I'd rather collect a set of topics to be discussed, invite a 
few more people to join the list (well, actually I can subscribe anybody 
;-)) and try to sort out things this way with some more input of more 
people.
>
>> There is _no_ status yet for both because I have no idea about the
>> proceedings. I planned to look into this as soon as there are regular
>> file releases for both packages.
>> The 0.2 release of 'musicexamples' isn't available ATM, and I will have
>> to change that release once more before making it available again,
>> because I have changed the copyright notice (in the hope there won't be
>> somebody who downloaded it in the few days and will make a problem out
>> of it.)
>> Probably that would be a candidate for a separate thread (if it still
>> has to be discussed), but I think we should license all source code
>> (i.e. LilyPond sources and LaTeX packages) with the GPL and the
>> 'creative' parts (documentation and tutorials) with CC BY-SA.
> Licensing needs extremely careful thought, because the bottom line of it is
> this: you want to be absolutely, absolutely certain of what derivative work you
> are staking a copyleft claim for.  I imagine we both agree that it's important
> that software and documentation deriving from your work should continue to be
> free-as-in-freedom, and equally that music written using your tools should be
> licensable as the composer/publisher/engraver wishes (and that would include .ly
> files as well as the graphical score produced).
Yes, definitely.
>   As things stand I have some
> severe doubts that raw GPL/CC-BY-SA would satisfy this requirement.
The CC-BY-SA part shouldn't be the problem, isn't it?
>
> One way to bypass that issue might be to use a permissive licence for code
> and/or documentation, such as the Boost or Apache licenses (for code) and CC-BY
> for docs.  It carries a certain risk, but you have to ask how seriously likely
> it is that someone would produce a proprietary derivative work in the first
> place, and how much damage it would actually do if they did.
>
> This MUST have been discussed with respect to Lilypond \include calls, so let's
> examine the past mailing list discussions and also raise the issue on -devel.
>
> ------------------------------------------------------------------------------
> Own the Future-Intel® Level Up Game Demo Contest 2013
> Rise to greatness in Intel's independent game demo contest.
> Compete for recognition, cash, and the chance to get your game
> on Steam. $5K grand prize plus 10 genre and skill prizes.
> Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d
> _______________________________________________
> openlilylib-user mailing list
> ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openlilylib-user

Re: [oll-user] Call for initial feedback

[Joseph R. W. <jos...@we...>]

On 03/28/2013 06:16 PM, Urs Liska wrote:
>> This seems to me to be unacceptable overreach on the part of the licensing.  It
>> may be worth raising this on the LP lists as it probably also applies to LP
>> \include's.
> _If_ that's the case that's in fact inacceptable.
> Looks like the perspective to another long running thread on 
> lilypond-user ...

... whoops .... :-\

Anyway, I'll draft that email to SFLC in the next days.