documentation. It would be great if somebody could create
properly-formatted patches for these corrections.
-Technical requirements: ability to run @ref{Lilybuntu}.
+Technical requirements: ability to run @ref{Lilydev}.
@item LSR editor:
LSR contains many useful examples of lilypond, but some snippets
often find them in Ponds of Lilies) and new feature implementors.
Technical requirements: development environment (such as
-@ref{Lilybuntu}), ability to read+write scheme and/or C++ code.
+@ref{Lilydev}), ability to read+write scheme and/or C++ code.
@end itemize
@warning{The estimated time required for "prep work", and the
following discussion, has been added to each item. At the moment,
-there is an estimated 30 hours of prep work and 125 hours of
+there is an estimated 30 hours of prep work and 140 hours of
discussion.}
@itemize
(prep: 2 hours. discuss: 10 hours)
+@item @strong{Separate branches for active development}:
+it might be good to have @emph{everybody} working on separate
+branches. This complicates the git setup, but with sufficient
+logic in lily-git.tcl, we can probably make it transparent to
+newbies. However, we'd need a reliable person to handle all the
+required merging and stuff.
+
+(prep: 2 hours. discuss: 10 hours)
+
+@item @strong{Precise definition of Critical issues}:
+at the moment, a stable release is entirely dependent on the
+number of Critical issues, but there's some questions about
+precisely what a "Critical issue" should be. We should clarify
+this, in conjunction with a general discussion about how often we
+want to have stable releases, how permissive we want to be about
+patches, etc etc.
+
+(prep: 1 hour. discuss: 5 hours)
+
+@item @strong{When do we add regtests?}:
+There is a discrepancy between our stated policy on adding
+regtests, and our actual practice in handling bugs and patches.
+Clarify.
+
+There is also a wider question how to organize the regtests, such
+as where to put interesting-console-output regtests, including
+stuff like lilypond-book and midi2ly in a sensible manner, and
+possibly including regtests for currently-broken functionality.
+
+(prep: 2 hours. discuss: 5 hours)
+
+@item @strong{code readability}:
+"Our aim when producing source code for Lilypond in whatever
+language is that it should be totally comprehensible to a
+relatively inexperienced developer at the second reading."
+
+Rationale:
+- aids maintainability of code base
+- "second reading" so newer developers can look up unfamiliar
+ stuff
+- will help to keep things simple, even if the code is doing
+ complex stuff discourages "secret squirrel" coding, e.g. "how
+ much functionality can I squeeze into as few characters as
+ possible" "comments are for wimps"
+- will aid not *discouraging* new developers to join the project
+
+(prep: 2 hours. discuss: 10 hours)
+
+@item @strong{C++ vs. scheme}:
+what should be in scheme, what should be in C++, what can/should
+be ported from one to the other, etc. Questions of
+maintainability, speed (especially considering guile 2.0), and the
+amount of current material in either form, are important.
+
+(prep: 5 hours. discuss: 15 hours)
+
@end itemize
Let users add their own items to the parser? comment 11 on:
http://code.google.com/p/lilypond/issues/detail?id=1322
+@item
+should engravers be pluralized (note_heads_engraver) or not
+(note_head_engraver) ?
+
+@item
+should we allow numbers in identifier names? Issue:
+http://code.google.com/p/lilypond/issues/detail?id=1670
+
+@item
+should we officially allow accented characters? in general, how
+do we feel about utf-8 stuff?
+
+@item
+for the sake of completeness/simplicity, what about *disallowing*
+the "one-note" form of a music expression? i.e. only allowing
+stuff like
+@verbatim
+ \transpose c d { e1 }
+ \transpose c d << e1 >>
+@end verbatim
+
+and never allowing
+@verbatim
+ \transpose c d e1
+@end verbatim
@end itemize
discuss giving them push access. Unsolicited requests from
contributors for access will almost always be turned down.
-
projects / lilypond.git / blobdiff