[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GSoC 2016
From: |
Urs Liska |
Subject: |
Re: GSoC 2016 |
Date: |
Tue, 26 Jan 2016 10:41:39 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 |
Am 26.01.2016 um 10:21 schrieb David Kastrup:
> Urs Liska <address@hidden> writes:
>
>> Would it be an acceptable/interesting project to bring the ScholarLY
>> library to a finished state and (optionally) integrate it with
>> LilyPond?
> Personally I don't think "integrating ScholarLY" with LilyPond is the
> right course: it is a rather special-purpose case. I think the question
> we should rather solve is how to modify LilyPond and its tools and
> infrastructure such that it becomes easy to fetch, drop in, and maintain
> things like ScholarLy when developed externally.
>
> Basically CTAN for LilyPond. I mean, the acronym CLAN is actually nice.
>
> What we distribute as "LilyPond core" should be a reasonably cohesive
> set of features and capabilities. If the coverage of musical issues
> provided outside of the core is more diverse and spotty and of different
> quality, that's then the responsibility of "special interest groups"
> rather than the LilyPond core developers. It would also allow people to
> contribute to a community without having to integrate themselves into
> the communications and working style of the core development.
>
> I'm not sure that this aspect is something that would work well as a
> GSoC project. With regard to the "bring to a finished state" angle, you
> are probably the best judge of how well-suited as a project that would
> be, likely with yourself as tutor.
>
Actually what you are writing is very much what I am thinking. ScholarLY
(and all the other conceivable libraries) are indeed better suited for
external development and maintenance.
There is actually some work going on towards something like a CTAN for
LilyPond. But less a CTAN but rather a tool that intends to fetch,
install and load packages/libraries from arbitrary (publicly available)
Git repositories. One person (i.e. not me) is actively working on a
prototype, and I think we (he)'ll bring it to a wider (developer)
audience in the not-too-distant future.
So my question could be rephrased: Would it be acceptable to suggest a
GSoC project if such an external library is *not* going to be included
in LilyPond directly? With regard to the project I'm convinced that this
would work out in the context/frame of a GSoC project.
Urs
- GSoC 2016, Urs Liska, 2016/01/21
- Re: GSoC 2016, Paul Morris, 2016/01/21
- Re: GSoC 2016, Urs Liska, 2016/01/26
- Re: GSoC 2016, David Kastrup, 2016/01/26
- Re: GSoC 2016,
Urs Liska <=
- Re: GSoC 2016, David Kastrup, 2016/01/26
- Re: GSoC 2016, Paul Morris, 2016/01/26
- Re: GSoC 2016, Urs Liska, 2016/01/27
- Re: GSoC 2016, Urs Liska, 2016/01/27
- Re: GSoC 2016, David Kastrup, 2016/01/27
Mentor availability (was: GSoC 2016), Urs Liska, 2016/01/27