Am 24.05.2012 10:57, schrieb Colin Hall:
On Thu, May 24, 2012 at 01:24:11PM +0800, James Harkins wrote:
Not sure if this was already discussed (I've been following the thread
somewhat loosely), but it seems to me that git makes it a whole lot
easier to handle a "build token" by virtue of the repositories being
decentralized.
Yes, it does, especially if there are clear boundaries between the
responsibilities of the contributors. This seems to be the case for
Urs, and probably a lot of lilypond projects, and my introduction of
the build token idea was not a useful contribution. Sorry for that.
Git is really awesome.
Agreed.
How about Urs, Susan, you and I collaborating on a one-page score via github as
a way of confirming our understanding, and demonstrating how it can be done?
Even a few staves would be enough to confirm a suitable workflow.
Keep it very simple. Something that any of us could write in thirty minutes,
say, on our own, but share the work via git.
Cheers,
Colin.
Hi all,
I was just busy writing to express my gratitude for all this input.
By now I think I have acquired enough information to be contented. So
while still being interested in reading anything more, I'd say nobody
_needs_ to give more of his/her time.
I have for some time now being decided to go for working with git.
But I won't make any experiments with our current project. This project
triggered my thinking about this subject - but as we're rapidly approach
the publication date, and we're in this case only two people having to
keep the integrity of the project, it will work the way we started. And
it's way too late to try out fundamental changes ...
I have a project in mind which will become my first bigger experience
with a git repository: an open library with many tools and concepts we
developed during the project (including quite some very clever coding we
profited from on this list and bug-lilypond). But I will only start to
think of it when the current project is ready.
And now to your idea, Colin: I find this is a very good idea.
For me personally this would be an opportunity to make sure I'm already
on the right track when starting the library project. And to get
feedback and discussion on the way.
I would suggest documenting such an experiment, so it will become useful
for others.
And I suggest to set the ground 'privately' (say: we four) and then open
it up for others from the list so we have more contributors and thus
more 'potential' of collisions.
I suggest that I will come back to you privately when our current
edition is finished. I would then setup a free github account, and we
would start thinking about what to do concretely.
If anyone wants to start right now, then of course: do. But I probably
won't be very active until mid/end June.
And (I stated already, but maybe I should repeat this here: I don't have
any practical experience with versioning systems (although I'm surely
'techy' enough to get it quickly ...))
This experiment could well also serve as a pre-test for a larger idea
that I have in mind (maybe for 2013): I would like to do a 'public
experiment' on how fast and efficient we can collaboratively produce a
large score - thanks to the text based approach. I'd like to do this as
a proof-of-concept project to promote some of LilyPond's qualities to a
wider target group ...
Imagine a large symponic movement (or possibly something oratoric) from
the end of the 19th century (so it's in the public domain) of 10
minutes. If we'd have 20 contributors, each dealing with one or two
parts, it should grow very speedily, documented through daily builds.
Maybe we could even find something that we can produce as a first
edition, which would give us quite some attention in the scholarly world
of music edition (furthermore: this _could_ generate money for the
development of Lilypond - provided one agrees upon not to give the
result to the public domain. One could for example make a score freely
available but keep the performance rights (an editor of a first edition
can hold the performance rights for 25 years, the royalties are similar
to those of the copyright of a composer). But that's nothing do discuss
already now ... ).
[
This is one of my goals on a grander scale: convince as many editors as
possible of LilyPond's qualities and potential (therefore the mentioned
library also stresses concepts in that direction (support of editorial
annotations, in-source communication or -documentation. And I have some
more ideas that can't be quickly hacked but might hopefully be realized
in the future: Support for pdf layers, a script that extracts 'critical
comments' from the sources ...)).
If responsible editors, say of Critical Editions start getting convinced
of LilyPond, it may increase the pressure on the publishers to slowly
tolerate the use of LilyPond. I won't say I have influence in this area,
but I will definitely do some lobbying with a few important Complete
Editions and also universities ...
]
Best
Urs
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
