* Motivation::
* Ongoing jobs::
* Policy decisions::
+* Policy decisions (finished)::
@end menu
@node Motivation
(prep: 5 hours. discuss: 15 hours)
+@item @strong{always make an issue number for patches}:
+there is a proposal that we should always have a google code issue
+number for every patch. This proposal is closely tied to our
+choice of patch review tool; if we switch to a different tool (as
+suggested in a different proposal), this proposal may become moot.
+
+(prep: 1 hour. discuss: 5 hours)
+
+@item @strong{initalizer lists}:
+shoudl we use initalizer lists for C++? AFAIK they make no
+difference for built-in types, but there's some weird case where
+it's more efficient for objects, or something.
+
+Probably not worth making this a weekly thing on its own, but we
+can probably wrap it up with some other code-related questions.
+
+(prep: 15 minutes. discuss: 3 hours)
+
+@end itemize
+
+@node Policy decisions (finished)
+@subsection Policy decisions (finished)
+
+@subheading GOP-PROP 1: python formatting
+
+We will follow the indentation described in PEP-8.
+@uref{http://www.python.org/dev/peps/pep-0008/}
+
+@itemize
+@item
+use 4 spaces per indentation level
+
+@item
+never mix tabs and spaces (for indentation)
+
+@item
+Code indented with a mixture of tabs and spaces should be
+converted to using spaces exclusively
+
+Once this is done, we should add @code{python -tt} to the build
+system to avoid such errors in the future.
+
@end itemize
+There should be absolutely no tab characters for indentation in
+any @code{.py} file in lilypond git. All such files should be
+converted to use spaces only.
+
@node Grand LilyPond Input Syntax Standardization (GLISS)
@end verbatim
? patch here:
+@smallexample
@uref{http://lists.gnu.org/archive/html/lilypond-devel/2010-04/msg00467.html}
+@end smallexample
@item
Personally, I find it easier to understand when there's a repeated
@item
Discussion on
-http://code.google.com/p/lilypond/issues/detail?id=1322
+@uref{http://code.google.com/p/lilypond/issues/detail?id=1322}
about \new vs. \context.
@item
Let users add their own items to the parser? comment 11 on:
-http://code.google.com/p/lilypond/issues/detail?id=1322
+@uref{http://code.google.com/p/lilypond/issues/detail?id=1322}
@item
should engravers be pluralized (note_heads_engraver) or not
@item
should we allow numbers in identifier names? Issue:
-http://code.google.com/p/lilypond/issues/detail?id=1670
+@uref{http://code.google.com/p/lilypond/issues/detail?id=1670}
@item
should we officially allow accented characters? in general, how