-@c -*- coding: utf-8; mode: texinfo; -*-
+Elu@c -*- coding: utf-8; mode: texinfo; -*-
@node Issues
@chapter Issues
@menu
* Introduction to issues::
-* Bug Squad overview::
-* Bug Squad setup::
-* Bug Squad checklists::
+* The Bug Squad::
* Issue classification::
* Adding issues to the tracker::
* Patch handling::
@node Introduction to issues
@section Introduction to issues
-@warning{Unless otherwise specified, all the tasks in this chapter
-are @qq{simple} tasks: they can be done by a normal user with
-nothing more than a web browser, email, and lilypond.}
+@warning{All the tasks in this chapter require no programming skills and
+can be done by anyone with a web browser, an email client and the
+ability to run LilyPond.}
-@qq{Issues} isn't just a politically-correct term for @qq{bug}.
-We use the same tracker for feature requests, code TODOs and
-patches, so the term @qq{bug} wouldn't be accurate. Despite the
-difference between @qq{issue} and @qq{bug}, we call our team of
-contributors who organize issues the @emph{Bug Squad}.
+The term @q{issues} refers not just to software bugs but also includes
+feature requests, documentation additions and corrections as well as any
+other general code @q{TODOs} that need to be kept track of.
-The Bug Squad is mainly composed of non-programmers -- their job
-is to @emph{organize} issues, not solve them. Their duties
-include removing false bug reports, ensuring that any real bug
-report contains enough information for developers, and checking
-that a developer's fix actually resolves the problem.
-
-New volunteers for the Bug Squad should contact the
-@ref{Meisters, Bug Meister}.
-@node Bug Squad overview
-@section Bug Squad overview
+@node The Bug Squad
+@section The Bug Squad
-The Bug Squad are volunteers who progress issue tracking using the
-Google Issue tracker at
+@menu
+* Bug Squad setup::
+* Bug Squad checklists::
+@end menu
-@example
-@uref{http://code.google.com/p/lilypond/issues/list}
-@end example
+To help keep track and organize all issues are a group of tireless
+volunteers collectively known as the @emph{Bug Squad}. Composed mainly
+of non-programmers, the Bug Squad's responsibilities include:
-Bug Squad members have 2 primary responsiblities:
+@itemize
-@enumerate
+@item
+Monitoring the LilyPond Bugs mailing list looking for any issues
+reported by other users ensuring that they are accurate and contain
+enough information for the developers to work with, preferably with
+@rweb{Tiny examples} and if applicable, screenshots.
@item
-Monitoring the LilyPond Bugs mailing list and adding to the
-tracker any new issues reported there.
+Adding new issues to the @emph{issue tracker} or updating existing
+issues with new information.
@item
-Verifying issues that are claimed fixed by a developer, to ensure
-that the fix works, and is actually in the code base.
+Verifying issues in the @emph{issue tracker} that have been marked
+as @q{fixed}; making sure either that the fix works or (in the case of
+Documentation for example) has at least been commited to the code base.
-@end enumerate
+@end itemize
-It's also part of the Bug Squad's responsibility to check that
-the Regression Tests don't show up any problems in the latest
-release. The Bug Meister currently does this.
+The @ref{Meisters, Bug Meister} also helps check the current
+@ref{Regression tests} and highlights any significant changes (or
+problems) since the previous LilyPond release.
+
+If you would like to be part of the Bug Squad, please contact the
+@ref{Meisters, Bug Meister}.
-All of this is explained in more detail in the following sections.
@node Bug Squad setup
-@section Bug Squad setup
+@subsection Bug Squad setup
We highly recommend that you configure your email to use effective
sorting; this can reduce your workload @emph{immensely}. The
@node Bug Squad checklists
-@section Bug Squad checklists
+@subsection Bug Squad checklists
When you do Bug Squad work, start at the top of this page and work
your way down. Stop when you've done 20 minutes.
the currently-active Bug Squad member(s) can handle the message.
-@subsubheading Daily schedule
+@subsubheading Daily schedule as of July 2015
@example
-Monday: Eluze
-Tuesday: Ralph Palmer
-Wednesday: Marek Klein
-Thursday: Eluze
-Friday:
-Saturday: Colin Campbell
-Sunday: Federico Bruni
+Monday: Federico Bruni
+Tuesday: Simon Albrecht
+Wednesday: Simon Albrecht
+Thursday: Colin Campbell
+Friday: Ralph Palmer
+Saturday: Colin Campbell
+Sunday:
@end example
separate person handling this task.}
For contributors/developers: follow the steps in
-@ref{Commits and patches}, and @ref{Pushing to staging}.
+@ref{Commits}, @ref{Patches}, and @ref{Pushing to staging}.
@ignore
For people doing maintenance tasks: git-cl is adding issues, James
The text of the email sets the deadline for this countdown batch. At
present, batches are done on Tuesday, Thursday and Sunday evenings.
-The body of the email lists the patches grouped by patch type, and for
-each patch, shows the tracker issue number and title, with a link to
-the Rietveld item. Copying the information from the website and pasting
-into the email gives a hyperlinked version of the information.
-
-@smallexample
-
-For 20:00 MST Tuesday January 8:
-
-Crash:
- Issue 2990: \RemoveEmptyStaves in StaffGroup context crashes - R 7069044
-
-Defect:
- Issue 677: \score markup confuses paper settings - R 7028045
- Issue 3050: displayLilyMusic produced erroneous code for rightHandFinger arguments - R 7032045
-
-Documentation:
- Issue 2952: Upgrade documentation of \once - R 7031053
- Issue 3044: Dual license the files under mf/ using OFL. - R 6970046
- Issue 3084: [DOC]Add "Known issue" in NR 1.2.1 about Scaling durations with rational numbers - R 7071044
-
-Enhancement:
- Issue 3061: make \articulate handle colon-type tremolos - R 7033045
- Issue 3082: Patch: Let ChordNameVoice use the same performers as Voice - R 7054043
- Issue 3083: Patch: Chord change detection in fretboards should depend on placements, not notes - R 7062043
- Issue 2983: assertion failed with \glissando - R 6625078
+To create the countdown announcement, use the
+@code{make-countdown-announcement.sh} script, which takes the
+deadline date, and optionally your name. Follow the instructions
+provided:
+@example
+cd $LILYPOND_GIT
+scripts/auxiliar/make-countdown-announcement.sh "Jan 1, 2001" James
+@end example
-Cheers,
-Colin
+The script produces an announcement that is easily readable in all
+email clients. Also, whenever a new contributor submits a patch,
+you will be prompted to add the new username and author name to
+the script itself, and then commit those changes to the main git
+repository.
-@end smallexample
@item
On the scheduled countdown day, the Patch Meister reviews the