-@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
-Wednesday: Marek
-Thursday: Joe Wakeling (soon)
-Friday: Colin H
-Saturday: Colin H
-Sunday: Federico
+Monday: Federico Bruni
+Tuesday: Simon Albrecht
+Wednesday: Simon Albrecht
+Thursday: Colin Campbell
+Friday: Ralph Palmer
+Saturday: Colin Campbell
+Sunday:
@end example
fails, Patchy sets it to @qq{patch-needs_work} and notifies the developer list.
@item
-The Patch Handler reviews the tracker periodically, to list patches
+The Patch Meister reviews the tracker periodically, to list patches
which have been on review for at least 24 hours. The list is found at
@smallexample
each patch.
@item
-The Patch Handler sends an email to the developer list, with a fixed
+The Patch Meister sends an email to the developer list, with a fixed
subject line, to enable filtering by email clients:
@example
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 Handler reviews the
+On the scheduled countdown day, the Patch Meister reviews the
previous list of patches on countdown, with the same procedure and
criteria as before. Patches with no controversy can be set to
@qq{patch-push} with a courtesy message added to the comment block.
@item
-Roughly at six month intervals, the Patch Handler can list the
+Roughly at six month intervals, the Patch Meister can list the
patches which have been set to @qq{patch-needs-work} and send the
results to the developer list for review. In most cases, these
patches should be marked @qq{patch-abandoned} but this should come
projects / lilypond.git / blobdiff