lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: critical issues


From: Janek Warchoł
Subject: Re: critical issues
Date: Tue, 3 Jan 2012 21:47:14 +0100

2012/1/3 David Kastrup <address@hidden>:
> Janek Warchoł <address@hidden> writes:
>
>> 2012/1/3 David Kastrup <address@hidden>:
>>> The Learning Guide and the Notation Guide need a complete rereading and
>>> reorganization, and it is not like the Extending Guide is in
>>> significantly better shape.
>>
>> I'd like to fix them too, but i don't have time for everything i want
>> :(  Splitting my time doesn't look like a good idea - it's more
>> effective when i put all my foxus on one thing, analyze it deeply and
>> make a complete solution than swap issues.  I have to choose and i
>> choose improving graphical output.
>
> I am a TeX specialist, system programmer, Emacs specialist, the GNU
> maintainer (and a rather pitiful one) for AUCTeX (lytex and itexi
> anybody? preview-latex for Lilypond?), know how to make Emacs read data
> from Midi ports, am pretty good concerning compiler writing, shell
> scripting, general programming, efficient algorithms, am the resident
> quiz person for git and so on and so on.
>
> I would have no problems spending a few hundred man years focused on
> Lilypond.  Except that I don't have a few hundred man years.  Nobody
> has.  The next best option is spending time on multipliers.  Getting
> LilyPond in a shape where passersby find it intriguing, to a degree
> where they get hooked and contribute manmonths of work over some time
> without having planned to do so at the start.

+1

> LilyPond has great infrastructure: it makes by far the most from Texinfo
> from any application I know, with much better HTML than upstream, far
> more thorough and good use of images (only useful in HTML or with Emacs
> as info reader, I am afraid).  I have no clue why or how GUB works, but
> many others don't have something like that.  It has good facilities for
> internationalization.  There are other novel pieces that turn out to be
> more of a maintenance problem than an asset because of a total lack of
> documentation and/or mindshare: yaffut, the organization of the C++
> core, many internals, stepmake, ...  Many corners are lying dormant
> since their respective driving force went away or lost interest or time.
>
> I don't manage to keep up with code reviews and am pretty sure that
> there are maintenance time bombs creeping in all the while.
>
> The only thing that is going to help is more eyes, more people who get
> interested, more people discovering dark corners and doing something
> about them.

+1

> LilyPond needs to get into a state where, say, half the
> engravers are written and maintained in Scheme.  And by "Scheme" I don't
> mean "Scheme at the level Nicolas can barely handle" but "Scheme a
> Fortran programmer would not have all too much of a problem
> understanding".

Umm, impossible?  From my perspective, 'Scheme' and 'easy to
understand' are mutually exclusive.  Unless there are more comments
than code - literally - but we don't do so.

> To get there, we need serious programmers and serious musicians
> interested seriously in LilyPond.  To a level where they start asking
> good questions.  And we better be in a position to provide answers,
> since there is no more effective way to spend our time than on getting
> more people to spend their time, and love, and interest.

That's like +1111 from me!
In general, i agree that we should think in a more 'release-oriented'
way ("last stable release was half a year ago, so we should make
another one, so i'm fixing whatever needs to be fixed to make this
possible") instead of 'free coding' way ("i care about this issue,
i'll fix it.  And that one.  Oh, we have 0 criticals, so let's make a
stable release before an obstruction occurs!").  To do so, we would
have to work more as a team, less independently.  How can we achieve
that if GOP7 showed that we don't want to?

By the way, you mentioned earlier that there are issues much more
severe and threatening to Lily 'stability' than those currently marked
as critical.  This made me curious.  Can you elaborate?

> And we better be in a position to provide answers,
> since there is no more effective way to spend our time than on getting
> more people to spend their time, and love, and interest.

The only "easy" way of moving towards this goal which i see is adding
comments to the code, explaining what it does (and thus making it
easier to provide answers).  Some time ago i was looking at horizontal
spacing code and i didn't understand anything.  I was also recently
trying to make Lily place augmentation dot differently with my friend
Luke (who is, unlike me, a programmer) - it took us a few hours to
figure it out.  I seriously think that Lily code could (and should) be
better described internally.  What do you think?

thanks,
Janek



reply via email to

[Prev in Thread] Current Thread [Next in Thread]