Re: GSoC 2014

[David Kastrup]

Jan-Peter Voigt <address@hidden> writes:

> Hi Janek, David, Urs,
>
> I agree, that the shape-project in fact is a project *and* IMO it is a
> very important one.
> But if I understand Davids concerns correctly, I agree, that it will be
> difficult to define boundaries for this project.

Well, let's put this in perspective.  This was a call on the GNU
maintainer list for proposing projects within 12 hours.  That basically
requires turnkey-ready proposals, and Urs volunteered what basically
amounted to buzzwords referring to ongoing work that had no obvious
publicly available roadmap or shape.  By the time the flames dies down,
there were few hours left anyway.

We have had previous experience with a Google Summer of Code project.
With a somewhat less general goal fleshed out in an itemized list of
specifications rather than a list of bad examples, requiring less
geometric work and iteration over shapes, and starting with a student
where "100 hours to get acquainted with the code base", in my opinion
quite too optimistic for a task of the tie formatting kind, was not even
required since the code base was known.

At the current point of time, there are almost no tangible results in
LilyPond proper.

I see no reason to assume that we'll fare better with a larger task that
is less clearly defined, placed on a student not previously acquainted
with the LilyPond code base.

Also a GSoC project requires a mentor and the obvious choice for this
task, namely Janek, is currently suffering a severe shortage of time.
The purported deadline has passed by now, the discussion about it thus
seems academic.  It may be more relevant next year again.

In afterthought, I could have thought of a few reasonably well-confined
projects which I could have defined and tutored myself quite well, like
a replacement of the basic skyline code, a major contributor to
LilyPond's runtime.

Or, somewhat more fuzzy, a rewrite of the page builder for flexibility
and performance.

But within the time frame of 12 hours, fleshing such stuff out is simply
not doable.  Perhaps there were previous calls on the GNU maintainer
list months ago.  If they were, I suppose I skipped over them.

> Your hard work on this topic is very important and I hope it will be
> rewarded the one or the other way!

Of course.

> I just think that the guile v2 project is better suited for GSoC.

It's not really a question of "better" or "worse": there was nothing
that would have kept us from proposing a dozen projects.

The most important thing about this "project" is that it's progressive.
If it only gets done to 40% or 70%, then 40% or 70% of the work does not
need to get touched again even when someone else has to finish it.
Assuming that most of the work can be done in master rather than a
branch.

> Davids proposal for integration of guile v2 is also a proposal of a
> very important project, because the day, lilypond needs to keep a
> legacy guile lib against newer versions installed versions by default
> is not that far away.

I have already been told by the Mageia maintainer that LilyPond would
likely stop getting distributed by them if it continues to require
GUILEv1.  While I'm not sure if and when this threat will come true, we
_are_ pissing off distribution maintainers by now with this requirement.

> And this project has a well-defined border: Make lilypond compile
> against guile v2 and integrate it in GUB.

I don't think that GUB would be part of the GSoC deal, but it's not like
swapping GUILE in GUB should be terribly complicated.

> And this would also be a giant leap for musicXML integration (and so
> on).

Not really: the XML libraries are also available for GUILEv1.  But in
general, large-scale architecture extensions should not be done based on
GUILEv1.  That does not make sense.

I've stalled
<URL:http://code.google.com/p/lilypond/issues/detail?id=2716> for quite
a while yet since some parts of it would be better/differently done
using GUILEv2.

> If this project is successful, we get this for free ;)

And most importantly: if it is not successful completely, we still get
something back in proportion to the work that could be done.

-- 
David Kastrup