On 7 Dec 2007, at 12:20, Valentin Villenave wrote:
The point is: we do *not* have enough people to handle all this (so
this is a very different situation from other places you've been used
to). LilyPond is:
- a huge project
- a large community
- a very small development team, with only volunteers that have "real"
lifes, "real" jobs and therefore are often unable to deal with the
bugs.
By narrowing the problem, you help soving it, you can save the
developers some precious time. An example: consider a developer who
has only two hours left. If he's only dealing with "minimal" snippets
could probably solve, say, 15 bugs, whereas if the snippets are large,
require him to do some tests, trials etc he could solve only 5 bugs or
less...
The problem is that a user which does not know anything about actual
LilyPond debugging is in a rather poor position doing the actual
reduction you want to see unless you tell how. This is normal in bug
reporting. I think you need to have at least one developer accessible
to have a look at the bug reports before filing; this way others will
learn, and the long term developer effort will be reduced.
All the bug reporting process is described on
http://lilypond.org/web/devel/participating/bugs
Granted, it's not very easy to find, but it does exist.
If you want people to follow this, simplify it as much as possible.
For example, it would be good if you could make sure the "\paper
{ ragged-right=##t }" is not needed, somehow (a default in
LilyPond?). Things that users can't understand why it should be
there, no matter how useful it is to developers, is likely to drop
out anyway in the user's bug reports.
Hans Åberg
_______________________________________________
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
