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)
+
@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) ?
@end itemize
discuss giving them push access. Unsolicited requests from
contributors for access will almost always be turned down.
-