openlilylib-user — General openLilyLib discussion

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

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

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

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

[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

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

[oll-user] Important update - first file release!

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

Today I managed to upload my first regular file release to SourceForge,
see http://www.openlilylib.org/?/musicexamples/

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

[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

[oll-user] New web site

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

Hi,

I have the first stub of a new web site online:

  * Content is managed by http://www.staceyapp.com
    -> seems a perfect solution for our needs
  * Layout is under control of the YAML CSS framework (http://www.yaml.de)
  * Content is managed through text files, so it will be simple to
    maintain it through Git

Next task will be to think about what we'll have to present on the site, 
i.e. think about one or more templates to subdivide that single content 
block there is so far. Issues are (e.g.): What texts should be there, 
which links to whom, (downloads will stay at sourceforge,) which pdfs 
will be there and how to access them etc.?

Best
Urs

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

Re: [oll-user] Ideas about simple content management system

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

Yeah, I made the first tests today. And if it doesn't turn out that it is full of bugs and limitations (which I don't expect) it is perfect for our needs - really a minimalistic approach to a CMS.



"Janek Warchoł" <lem...@gm...> schrieb:

>2013/3/14 Urs Liska <ul...@op...>
>
>> Unfortunately this means that we (I) have to find a reasonably simple
>> framework/infrastructure to manage the site. But it seems I've
>already been
>> lucky:
>> http://www.staceyapp.com/
>> [...] we can maintain the whole site with a git repository.
>>
>> Anybody any experience with stacey?
>> Or any other ideas for a lightweight but complete solution I should
>check
>> out?
>>
>
>nope&nope.
>
>your suggestion looks reasonable :)
>Janek

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
-------------- next part --------------
An HTML attachment was scrubbed...

Re: [oll-user] Ideas about simple content management system

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

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

> Unfortunately this means that we (I) have to find a reasonably simple
> framework/infrastructure to manage the site. But it seems I've already been
> lucky:
> http://www.staceyapp.com/
> [...] we can maintain the whole site with a git repository.
>
> Anybody any experience with stacey?
> Or any other ideas for a lightweight but complete solution I should check
> out?
>

nope&nope.

your suggestion looks reasonable :)
Janek
-------------- next part --------------
An HTML attachment was scrubbed...

[oll-user] Ideas about simple content management system

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

Hi folks,

the first 'real' message from me to this list.
Please ignore if you don't feel competent or interested.

I just stumbled over the first (hopefully small) drawback of our sourceforge approach:
While they provide a generous 'project web' they are right now discontinuing their 'hosted apps' feature.
This feature included a wide array of web apps - including for example Content Management Systems - that were hosted and managed by the sourceforge team but could be used for any project.
The project web still allows to install and run a wide array of applications
(see https://sourceforge.net/p/forge/documentation/Project%20Web%20Services/)
but now one has to install and manage them oneself.

So we have web space (apparently without explicit limits), shell access to that and an array of the usual languages "including PHP (via mod_php), Perl, Python, Tcl, Ruby, and shell scripts. Support for several database platforms is provided, including MySQL (through our Project Database service), DBM, and SQLite."

Unfortunately this means that we (I) have to find a reasonably simple framework/infrastructure to manage the site. But it seems I've already been lucky:
http://www.staceyapp.com/
seems to be ideal, because it looks really lightweight, basically the most rudimentary implementation of a template driven content management system.
Despite any pretension we have about our content, the web site is in the end a rather small project with a quite manageable number of (different) pages.
If stacey does what it pretends it is a small PHP application that takes HTML templates and feeds them with content that is stored in plain text files. To create additional pages one simply has to add a text file with content. So it is clear that we can maintain the whole site with a git repository.

Anybody any experience with stacey?
Or any other ideas for a lightweight but complete solution I should check out?

Best Urs

Re: [Openlilylib-user] Startup-test

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

i see it :)


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

> Hi list (guess who you are so far ...)
>
> let's see how this message goes through
>
> 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...

[Openlilylib-user] Startup-test

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

Hi list (guess who you are so far ...)

let's see how this message goes through

Best
Urs