Re: issue classification: priority guidelines

[Carl Sorensen]

On 12/15/10 8:32 AM, "Janek Warchoł" <address@hidden>
wrote:

> 2010/12/15 Graham Percival <address@hidden>
>>  Fighting about whether a bug should be high vs. low does NOTHING
>> to get it fixed sooner or later.  This is a volunteer project, and
>> lilypond developers do not appear to be motived based on an
>> arbitrary "priority" field.  The main motivating factors appear to
>> be:
>> 1. somebody wants that notation added (or bug fixed) for a
>> personal score
>> 2. it "looks easy enough" to attempt
>> 3. money (i.e. if somebody offers a bounty, or hires somebody with
>> a grant)
> 
> Ok, this means i have to fix some (lots of?) stuff myself (you got me
> hooked perhaps, however i don't know how all this will turn out)...
> 
<snip>
> Unfortunately, none of the above told me what's actually happening
> when lilypond is run, so when i tried to look at the code, for example
> stem.cc, i barely understood anything :\
> So if you know of any source of knowledge that may be useful for me,
> i'd appreciate it.

Everything we have documented is in the Contributor's Guide.

Getting started in LilyPond development is hard.

Understanding how lilypond works is hard.

Understanding the C++ code is hard.

I wish I had better answers, but I don't.  But it's not impossible.  And
it's fun to improve LilyPond.  And when you get better answers, you can
contribute them to the CG to make it easier for the next person.

Section 9.1 of the Contributor's Guide gives the 30-second overview of how
LilyPond works.  It is, however, missing a description of the output stage,
when she code that produces the postscript or svg commands is actually
executed.

Section 9.7 of the CG gives a rundown of a process used to trace the object
relationships that might help you better understand how lilypond works.
Give it a try.

A debugger might help, but I find it LilyPond to be so complex in its
execution that tracing it through a debugger is rarely helpful.

If you search through the source code (along with studying chapter 9 of the
Contributor's Guide) and then come up with specific questions about the code
that you're studying, I'd expect that we'll be willing to answer them.

Thanks,

Carl