Il giorno dom 19 lug 2015 alle 0:58, Urs Liska ha
scritto:
But it *is* a problem that changing anything on the website is such an
involved process - both in terms of the used infrastructure *and* in
terms of the review process. This *is* scaring away people who would
be
able to support the pro
Werner, I'm skipping your replies where you were implying that I was
proposing to change the whole documentation system and not just the
website.
Il giorno dom 19 lug 2015 alle 7:26, Werner LEMBERG ha
scritto:
1. All the persons who built the lilypond build system left the
project. C
Il giorno dom 19 lug 2015 alle 7:33, Werner LEMBERG ha
scritto:
Federico suggests that *the website* doesn't have to be available in
PDF or info format. He doesn't speak of manuals.
This fine distinction was definitely not obvious in his first e-mail.
Really?
Quoting myself, "tool for the
> But the "website" doesn't have to be available as PDF or as info
> documents if the manuals are. So I don't see anything speaking
> against having a "website" that is developed using arbitrary
> technologies that may even change every two years and having the
> manuals in their traditional infr
As a preliminary I want to mention that in general I can imagine that
we separate the top-level entry page of lilypond.org from the texinfo
system. Somewhere we could have a `doc' subdirectory, and from there
on everything is generated with texinfo as usual.
> I understand that having to learn t
Hi,
I don't really like to join the discussion, because a) I don't like to
tone and b) I don't have time to work on changes or even proposals.
But I'd like to second the general idea by Federico. A website creation
less carved in stone and with easier maintainability is something to aim
at. Any s
I'm afraid David is right with many things here, although I'd prefer him
being more moderated in his tone. Federico is laying his finger on an
obviously problematic issue, and he's actively thinking about possible
solutions. Maybe his ideas aren't going to work out for inherent
problems, maybe not
One thing that you have to be aware of is that
#{ \music #}
is not equivalent to music but rather to
(ly:music-deep-copy music (*location*))
since it creates a copy of the music and puts the point-and-click
information to the call of the containing music function.
Now I don't really know whether
Federico Bruni writes:
> Il giorno sab 18 lug 2015 alle 20:42, David Kastrup ha
> scritto:
>> Federico Bruni writes:
>>
>>> Il giorno sab 11 lug 2015 alle 9:28, Urs Liska
>>> ha
>>> scritto:
These are all good ideas and suggestions. Now we need someone to
give it a try. I won't b
Il giorno sab 18 lug 2015 alle 20:42, David Kastrup ha
scritto:
Federico Bruni writes:
Il giorno sab 11 lug 2015 alle 9:28, Urs Liska
ha
scritto:
These are all good ideas and suggestions. Now we need someone to
give it a try. I won't be able to do anythong about ut
unfortunately.
U
Federico Bruni writes:
> Il giorno sab 11 lug 2015 alle 9:28, Urs Liska ha
> scritto:
>> These are all good ideas and suggestions. Now we need someone to
>> give it a try. I won't be able to do anythong about ut
>> unfortunately.
>
> Unfortunately I'm scared away by texinfo, texi2html, the build
2015-07-18 19:05 GMT+02:00 Federico Bruni :
>> $ git push origin HEAD:staging
>
> That's probably how I would like to work (so I don't need the patch file).
> `git fetch` fetches implicitly from a particular branch?
>
> What's the purpose of HEAD:staging?
moves the branch on remote to your recentl
Il giorno sab 11 lug 2015 alle 9:28, Urs Liska ha
scritto:
These are all good ideas and suggestions. Now we need someone to give
it a try. I won't be able to do anythong about ut unfortunately.
Unfortunately I'm scared away by texinfo, texi2html, the build system,
etc.
I wish we could use a
Benkő Pál writes:
> 2015-07-18 17:57 GMT+02:00 Federico Bruni :
>> What do you think about these instructions?
>> http://lilypond.org/doc/v2.19/Documentation/contributor/pushing-to-staging
>>
>> I have a few comments, but I'm not sure about any of them:
>>
>> 1. There's no real purpose in pulling
Il giorno sab 18 lug 2015 alle 18:33, Benkő Pál
ha scritto:
3. I don't like much the `git merge` approach suggested for those
who work
with local branches, as the git log is a bit messed up (a merge
commit is
added, often faraway from the commit containing the real changes).
I'd
rather su
2015-07-18 17:57 GMT+02:00 Federico Bruni :
> What do you think about these instructions?
> http://lilypond.org/doc/v2.19/Documentation/contributor/pushing-to-staging
>
> I have a few comments, but I'm not sure about any of them:
>
> 1. There's no real purpose in pulling and rebasing the staging br
- Original Message -
From: "Federico Bruni"
To: "lilypond-devel"
Sent: Saturday, July 18, 2015 4:57 PM
Subject: CG manual, pushing to staging
What do you think about these instructions?
http://lilypond.org/doc/v2.19/Documentation/contributor/pushing-to-staging
I have a few comments,
What do you think about these instructions?
http://lilypond.org/doc/v2.19/Documentation/contributor/pushing-to-staging
I have a few comments, but I'm not sure about any of them:
1. There's no real purpose in pulling and rebasing the staging branch,
assuming that this branch should be "clean" (w
18 matches
Mail list logo
