Jan-Peter Voigt <jp.vo...@gmx.de> 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 _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
