lilypond-devel
[Top][All Lists]
Advanced

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

Re: critical issues


From: David Kastrup
Subject: Re: critical issues
Date: Wed, 04 Jan 2012 15:31:29 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux)

Łukasz Czerwiński <address@hidden> writes:

> On 3 January 2012 21:47, Janek Warchoł <address@hidden> wrote:
>
>>
>> > 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?)
>
> Mmm... Preview for Lilypond? Sounds like a good start for a realtime
> GUI for Lilypond (a better Denemo). I believe this will result in a
> fast increase in number of Lilypond users. What do you think?

It won't.  People who are into Emacs won't be into Finale or Sibelius
anyway.  It will increase the ratio of LilyPond users using Emacs for
editing, and possibly the productivity of users of that combination.

But recruiting new users to both LilyPond and Emacs at the same time is
not going to show impressive results.

It is a reasonable expectation to get preview-latex cooperate with
lilypond-book in LaTeX mode with reasonable effort.  To yield a sizable
boost in productivity for LilyPond development, however, preview-latex
would have to cooperate with Texinfo.

Technologically, this is challenging and exciting.  Unfortunately, for
myself the excitement is somewhat stale since I already implemented
preview-latex once.

> Regarding all those fragments of Janek's and David's emails: For some time
> I have been observing how bug are being fixed in Lilypond and spent some
> time on conversations with Janek.
> For me there is almost no team work in Lilypond - only a bunch of geek
> trying to fix some issues, but without a leader who coordinates all
> actions.

We have coordinated procedures in place that several people spend
sizable amounts of time on.  This concerns the way new contributions are
channeled, and how bugs get registered and releases get made.  Graham is
doing a lot of work keeping just that going and coordinated.

New developments are not coordinated to a significant degree, and part
of the reason is that there are no free resources to coordinate.

> As far as I remember, some time ago you have tried hard to make some
> big changes in Lilypond, but finally there was no big revolution...

I am not sure who you are addressing.  Nominally, you are replying to
Janek, and Janek did spacing changes he not just tried to get through,
but actually did.  If you are trying to address my work: I did a lot of
big changes to LilyPond but you would not notice much of it unless you
read the manual, and even then much of it is underdocumented.  A lot of
it is hidden in making naively written code work and giving more power
more easily accessible to the somewhat above-average user as opposed to
the geniuses required before.

> Without a leader that will make key design & implementation decisions
> Lilypond will improve in a slow pace, letting Finale and Sibellius
> gain more and more users.

Forget Finale and Sibelius.  They are not a problem we need to address
since they are competing in a different space.  Our real problem is
LilyPond.

> Probably some of you will return to the old row - is a goal of a
> Lilypond to substitue Finale or compete with Sibellius. I think there
> is no point in loosing your energy *and time* on that.  Instead we
> should do as much as possible to constantly improve Lilypond.

Preaching to the choir, I see.

> That means not only fixing critical bugs, but also: anticipating
> future stability problems, constantly improving end user documentation
> and the quality of source code (reduce complexity, comment code and so
> on). By now there is a huge work to be done and Lilypond needs someone
> who will form guidelines and priorities.

There is no point in working on guidelines and priorities without
capacities that would be guided and prioritized by them.

-- 
David Kastrup




reply via email to

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