Am 10.01.2013 11:25, schrieb Jan-Peter Voigt:
Great!
I would like to join in and I am going to host my lib/framework on
github too with the option and goal of integration with openLilyLib
and/or later lilypond.
That's great too!
This morning I created a github account,
What's your user name? I'd like to add you.
The standard way to collaborate on a Github project is to
* fork a repo (i.e. create a personal copy of it)
* make modifications to your fork
* send a pull request (ask the maintainer to merge your changes into
the original repo)
While this is a perfect way to start participation in a project whose
maintainer doesn't know you, it's more straightforward to be an explicit
collaborator with push access to the repository.
And I think we can be rather generous with that.
so I am not familiar with its services (beside the usage of GIT).
... which is _far_ more than 50% of the problem (i.e. won't face you
with any serious problems.)
What are you missing regarding the issue tracker?
Sorry if I can't put my fingers on it very concisely (I'm still sort of
a beginner in these areas), but as a general remark I find it somewhat
too simplistic.
It's a tool that you can start to use right away (that seems to be
Github's objective in general), but the downside is that it isn't very
refined.
A few issues compared to LilyPond's issue tracker on Google Code:
* Filtering issues isn't very good
* You can't give priorities to issues
* No mechanism to verify issues
* No option to merge issues
* (don't find more right now, but there surely are)
Someone else pointed out that it is a real problem that one (i.e.
anybody) can edit issues and comments. You can change a message
afterwards without leaving a trace from that.
The only real 'advantage' of Githubs tracker is that it is integrated
with Git. So you can reference or close issues directly from commit
messages. This is nice, especially because you'll get a message in the
issue saying 'this issue was closed by commit <link>asdpfj02395</link>.
But I don't think that's really worth sticking to it.
Best
Urs
Best,
Jan-Peter
Am 10.01.2013 um 10:43 schrieb Urs Liska:
Am 10.01.2013 09:03, schrieb Janek Warcho?:
(i cannot resist my lilypond addiction...)
On Thu, Jan 10, 2013 at 12:09 AM, Urs Liska<li...@ursliska.de> wrote:
But I probably won't touch [online tutorial] until I reformat it as a PDF
version. There
had been some valuable comments on this list right after the first 'release'
of the tutorial - which still haven't been incorporated :-(
That's why git and github rock - someone could write the changes and
you'd just have to accept the pull request.
I strongly recommend using text input for such project (which is
really great BTW!), because text input make version control effective.
I understand that LaTeX might be scary for beginners. Maybe simply
use formatted plain text? (something like markdown, for example).
If nobody comes up with a better suggestion or serious objections -
or if nobody else just offers to maintain the project and wants to do
it differently - I will do the following:
* Host openLilyLib in the existing Github repository
(I didn't intend to start with this already, so it will be kind
of a stub for some time)
* Maintain the library's documentation and the tutorials (starting
with Antonio's proposed text on orchestral scores and hopefully
with a conversion of my existing tutorial) as a set of LaTeX
documents.
* I think there is no real alternative to this because
o LaTeX documents can be easily versioned with Git
o We are talking about LilyPond, so we wouldn't want to expose
anything less (e.g. a collection of inconsistently looking
PDFs created from various applications)
* These documents can then be rendered as individual files or as a
compiled 'book'.
* Contributors are encouraged to provide LaTeX sources too, but
o markdown or even plain text files would work too
o if we are talking about the contribution of complete
tutorials, it is also appropriate to aid in converting from,
say, reasonably structured OpenOffice or Word documents
o As a last resort we can even incorporate PDF documents (e.g.
in case someone stumbles over an existing PDF where the
sources have been lost ...)
* We have to decide upon platforms for a 'public frontend' to the
project, a mailing list and optionally an issue tracker (although
Github offers one)
Current suggestions point to use Google services for these parts.
Best
Urs
best,
Janek
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org <mailto:lilypond-user@gnu.org>
https://lists.gnu.org/mailman/listinfo/lilypond-user
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
