* Bug Squad checklists::
* Issue classification::
* Adding issues to the tracker::
+* Patch handling::
* Summary of project status::
-* Finding the cause of a regression::
@end menu
@enumerate
@item
-Skim through every section of this chapter, @ref{Issues}. Read in
-detail any sections called @qq{Bug Squad...}, or any page linked
-from @ref{Bug Squad checklists}.
+Read every section of this chapter, @ref{Issues}.
@item
If you do not have one already, create a gmail account and send
@enumerate
+@item
+Wait until your gmail account is listed in:
+
+@example
+@uref{http://code.google.com/p/lilypond/people/list}
+@end example
+
@item
Sign in to google code by clicking in the top-right corner of:
@uref{http://code.google.com/p/lilypond/issues/list}
@end example
+You cannot log on if you have Google Sharing enabled
+@uref{http://www.googlesharing.net/}.
+
@item
Go to your @qq{Profile}, and select @qq{Settings}.
@section 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 15 minutes.
+your way down. Stop when you've done 20 minutes.
Please use the email sorting described in @ref{Bug Squad setup}.
This means that (as Bug Squad members) you will only ever respond
@subsubheading Emails to you personally
You are not expected to work on Bug Squad matters outside of your
-15 minutes, but sometimes a confused user will send a bug report
+20 minutes, but sometimes a confused user will send a bug report
(or an update to a report) to you personally. If that happens,
please forward such emails to the @code{bug-lilypond} list so that
the currently-active Bug Squad member(s) can handle the message.
@subsubheading Daily schedule
-The Bug Meister is omitted from the daily schedule.
+@c spacing is deliberate to help reinforce the "cyclic" nature
@example
-Sunday: Colin
-Monday: Dmytro
-Tuesday: James Bailey
-Wednesday: Ralph
-Thursday: Patrick
-Friday: Urs
-Saturday: Kieren
+Monday: Dmytro
+Tuesday: Colin
+Wednesday: Derek
+Thursday: Dmytro
+Friday: Colin
+Saturday: Derek
+Sunday: Phil
@end example
@item
Issues to verify: try to reproduce the bug with the latest
-version; if you cannot reproduce the bug, mark the item
-@qq{Verified} (i.e. @qq{the fix has been verified to work}).
+official GUB version; if you cannot reproduce the bug, mark the
+item @qq{Verified} (i.e. @qq{the fix has been verified to work}).
@example
@uref{http://code.google.com/p/lilypond/issues/list?can=7}
for you to verify these. Leave those issues alone; somebody else
will handle them.
-@end itemize
-
-
-@ignore
-@c try omitting from daily tasks for now. -gp
-
-Once every @strong{two weeks} or so:
-
-@itemize
-
@item
Check for any incorrectly-classified items in the tracker. This
generally just means looking at the grid to see any items without
a Type or Priority.
-@item
-Check for any items with @code{label:patch}. If it's been more
-than a week since the last action on the issue, send an email to
--devel to remind them about it. If the patch was withdrawn for
-more work, then remove the @code{patch} label.
-
-@example
-@uref{http://code.google.com/p/lilypond/issues/list?can=2&q=label:patch}
-@end example
-
@end itemize
+@ignore
+@c try omitting from daily tasks for now. -gp
+
@subheading Irregular maintenance
@warning{These tasks are a lot of work; gathering more volunteers
@item
Type-Scripts: problem or desired feature in the non-build-system
scripts. Mostly used for convert-ly, lilypond-book, etc.
+
@item
Type-Enhancement: a feature request for the core program. The
distinction between enhancement and defect isn't extremely clear;
@itemize
@item
-Priority-Critical: lilypond segfaults, or a regression occurred
-within the last two stable versions. (i.e. when developing 2.13,
-any regression against 2.12 or 2.10 counts)
+Priority-Critical: LilyPond segfaults, a regression (see below)
+against a previous stable version or a regression against a fix
+developed for this version. This does not apply where the
+@qq{regression} occurred because a feature was removed
+deliberately - this is not a bug.
@item
-Priority-High: highly embarrassing items, and any regression
-against a version earlier than two stable versions (i.e. when
-developing 2.13, any regression against 2.8 or earlier). This
-level is also used for issues which produce no output and fail to
-give the user a clue about what's wrong.
+Priority-High: An issue which produces output which does not
+accurately reflect the input (e.g. where the user would expect
+an accidental, but none is shown) or which produces aesthetically
+poor output in a situation which could be expected to crop up
+frequently in real-world music. It should not be used where the
+problem can be avoided with a simple workaround. It can also
+be used to flag where new code in a development version is not
+functioning as it should. This level is also used for issues
+which produce no output and fail to give the user a clue about
+what's wrong.
@item
-Priority-Medium: normal priority.
+Priority-Medium: Normal priority - use this as the default.
@item
-Priority-Low: less important than normal.
+Priority-Low: A minor problem which produces slightly undesirable
+output, or which will only occur in contrived examples, or which
+is very easily worked around.
@item
Priority-Postponed: no fix planned. Generally used for things
-like Ancient notation, which nobody wants to touch.
+which nobody wants to touch.
@end itemize
-The difference between Priority-Medium and Priority-Low is not
-well-defined, both in this policy and in practice. The only
-answer we can give at the moment is @qq{look at existing items in
-of the same type, and try to guess whether the priority is closer
-to the Medium items or Low items}. We're aware of the ambiguity,
-and won't complain if somebody picks a @q{wrong} value for
-Medium/Low.
-
+Note that these are initial classifications and can be subject
+to change by others in the development team. For example, a
+regression against an old stable version which hasn't been
+noticed for a long time and which is unlikely to get fixed could
+be downgraded from Priority-Critical by one of the programmers.
@subheading Opsys (optional)
Issues that only affect specific operating systems.
+@subheading Patch (optional)
+
+Normal Bug Squad members should not add or modify Patch issues;
+leave them to the Patch Meister.
+
+@itemize
+
+@item
+Patch-new: the patch has not been checked for @qq{obvious}
+mistakes. When in doubt, use this tag.
+
+@item
+Patch-review: the patch has no @qq{obvious} mistakes (as checked
+by the Patch Meister), and is ready for review from main
+developers.
+
+Developers with git push ability can use this category, skipping
+over @code{patch-new}.
+
+@item
+Patch-needs_work: a developer has some concerns about the patch.
+This does not necessarily mean that the patch must be changed; in
+some cases, the developer's concerns can be resolved simply by
+discussion the situation or providing notation examples.
+
+If the patch is updated, the category should be changed to
+@code{patch-new} (for normal contributors) or @code{patch-review}
+(for developers who are very confident about their patch).
+
+@item
+Patch-abandoned: the author has not responded to review comments
+for a few months.
+
+@end itemize
@subheading Other items (optional)
@itemize
@item
-Regression: it used to @strong{deliberately} work in an earlier
+Regression: it used to work intentionally in an earlier
stable release. If the earlier output was accidental (i.e. we
didn't try to stop a collision, but it just so happened that two
grobs didn't collide), then breaking it does not count as a
regression.
+To help decide whether the change is a regression, and therefore
+should be Priority-Critical, please adopt the following process:
+
+@enumerate
+
+@item
+Are you certain the change is OK? If so, do nothing.
+
@item
-Patch: a patch to fix an issue is attached.
+Are you certain that the change is bad? Add it to the tracker
+as a Critical issue, regression.
+
+@item
+If you're not certain either way, add it to the tracker as a
+Critical issue, regression but be aware that it may be
+recategorised or marked invalid.
+
+@end enumerate
+
+In particular, anything that breaks a regression test is a
+regression.
@item
Frog: the fix is believed to be suitable for a new contributor
@end itemize
-If you particularly want to add an label not in the list, go
+If you particularly want to add a label not in the list, go
ahead, but this is not recommended.
In order to assign labels to issues, Bug Squad members should log
in to their google account before adding an item.
-@subsubheading Normal issues
-
@enumerate
@item
lilypond --png bug.ly
@end example
+@item
+Images created as @file{bug.png} may be trimmed to a minimum size
+by using the @code{trimtagline.sh} script, which can be found at
+@uref{https://raw.github.com/gperciva/lilypond-extra/master/bug-squad/trimtagline.sh}
+
+@example
+trimtagline.sh bug.ly
+@end example
+
@item
If the issue cannot be shown with less than three pages, then
generate a @file{bug.pdf} file with:
@end enumerate
-@subsubheading Patch reminders
+
+@node Patch handling
+@section Patch handling
@warning{This is not a Bug Squad responsibility; we have a
separate person handling this task.}
-There is a special category of issues: reminders of an existing
-patch. These should be added if a patch has been sent to a
-lilypond mailing list (generally @code{lilypond-devel}, but they
-sometimes appear on @code{bug-lilypond} as well) and has had no
-discussion for at least @strong{3 days}. Do not add issues for
-patches under active discussion.
+There is a single Patch Meister, and a number of Patch Helpers
+(rename this?). The list of known patches awaiting review is:
+
+@example
+@uref{http://code.google.com/p/lilypond/issues/list?can=2&q=label:patch&sort=patch}
+@end example
+
+
+@subheading Helpers: adding patches
+The primary duty is to add patches to the google tracker; we have
+a bad track record of losing patches in email. Patches generally
+come to the @code{lilypond-devel} mailing list, but are sometimes
+sent to @code{bug-lilypond}, @code{lilypond-users}, or
+@code{frogs} mailing list instead.
+
+@itemize
+@item
+Unless a patch is clearly in response to an existing issue, add a
+new issue with the @code{Patch-new} label and a link to the patch
+(either on the mailing list archives or the codereview url).
+
+Issue numbers are cheap; losing developers because they got fed up
+with us losing their hard work is expensive.
+
+@c if we enter patches immediately, I don't think this is relevant.
+@ignore
+@item
Before adding a patch-reminder issue, do a quick check to see if
it was pushed without sending any email. This can be checked for
searching for relevant terms (from the patch subject or commit
@example
@uref{http://git.savannah.gnu.org/gitweb/?p=lilypond.git}
@end example
+@end ignore
+@item
+If the patch is clearly in response to an existing issue, then
+update that issue with the @code{Patch-new} label and a link to
+the patch (either on the mailing list archives or the codereview
+url).
+
+@item
After adding the issue, please send a response email to the same
-group(s) that the initial patch was sent to. If the initial email
-was sent to multiple mailing lists (such as both @code{bugs} and
-@code{devel}), then reply to all those mailing lists as well. The
-email should contain a link to the issue you just added.
+group(s) that the initial patch was sent to.
+
+If the initial email was sent to multiple mailing lists (such as
+both @code{bugs} and @code{devel}), then reply to all those
+mailing lists as well. The email should contain a link to the
+issue you just added.
+
+@end itemize
+
+@subheading Helpers: @code{Patch-review} label
+
+The secondary duty is to do make sure that every issue in the
+tracker with a @code{Patch-review} label has passed these
+@qq{obvious} tests:
+
+@itemize
+@item
+Applies automatically to git master.
+
+It's ok to have offsets, but not conflicts.
+
+@item
+Regtest comparison looks ok; no unexpected changes.
+
+@item
+Descriptive subject line.
+
+Avoid subjects like @qq{fixes 123}; instead write @qq{Doc: discuss
+stacking-dir for BassFigureAlignment (fix 123)}.
+
+@item
+Compiles docs from scratch. Only check this if you have reason to
+suspect it might not work.
+
+@item
+(maybe)
+
+Check code indentation and style. This should be easier post-GOP
+when we have a better-defined code style.
+
+@end itemize
+
+
+@subheading Patch Meister
+
+The Patch Meister will:
+
+@itemize
+
+@item
+send @qq{countdown} emails to
+@code{lilypond-devel} when patches appear to be ready.
+
+@item
+send general requests to review patches, or even nasty requests to
+review patches.
+
+@item
+downgrade patches from @code{Patch-review} to
+@code{Patch-needs_work} as appropriate.
+
+@item
+downgrade patches from @code{Patch-needs_work} to
+@code{Patch-abandoned} if no actions have been taken in four
+weeks.
+
+@end itemize
+
@node Summary of project status
@section Summary of project status
-The best overview of our current status is given by the grid view:
+@subsubheading Project overview
-@example
+Grid view provides the best overview:
+
+@smallexample
@uref{http://code.google.com/p/lilypond/issues/list?mode=grid&y=Priority&x=Type&cells=ids}
-@end example
+@end smallexample
-Also of interest might be the issues hindering future development:
+@subsubheading Hindering development
-@example
-@uref{http://code.google.com/p/lilypond/issues/list?can=2&q=label:Maintainability&mode=grid&y=Priority&x=Type&cells=ids}
-@end example
+These issues stop or slow development work:
+
+@smallexample
+@uref{http://code.google.com/p/lilypond/issues/list?can=2&q=label:Maintainability}
+@end smallexample
-Finally, issues tagged with @code{Frog} indicates a task suitable
-for a relatively new contributor. The time given is a quick
+@subsubheading Easy tasks
+
+Issues tagged with @code{Frog} indicates a task suitable for a
+relatively new contributor. The time given is a quick
(inaccurate) estimate of the time required for somebody who is
familiar with material in this manual, but does not know anything
else about LilyPond development.
-@example
-@uref{http://code.google.com/p/lilypond/issues/list?can=2&q=label:Frog&mode=grid&y=Priority&x=Type&cells=ids}
-@end example
-
+@smallexample
+@uref{http://code.google.com/p/lilypond/issues/list?can=2&q=label:Frog}
+@end smallexample
-@node Finding the cause of a regression
-@section Finding the cause of a regression
+@subsubheading Patches to review
-@warning{This is not a @qq{simple} task; it requires a fair amount
-of technical knowledge.}
+Patches which have no @qq{obvious} problems:
-Git has special functionality to help tracking down the exact
-commit which causes a problem. See the git manual page for
-@code{git bisect}. This is a job that non-programmers can do,
-although it requires familiarity with git, ability to compile
-LilyPond, and generally a fair amount of technical knowledge. An
-in-depth explanation of this process will not be given here.
-
-Even if you are not familiar with git or are not able to compile
-LilyPond you can still help to narrow down the cause of a
-regression simply by downloading the binary releases of different
-LilyPond versions and testing them for the regression. Knowing
-which version of LilyPond first exhibited the regression is
-helpful to a developer as it shortens the @code{git bisect}
-procedure described above.
+@example
+@uref{http://code.google.com/p/lilypond/issues/list?can=2&q=label:patch-review}
+@end example
-Once a problematic commit is identified, the programmers' job is
-much easier. In fact, for most regression bugs, the majority of
-the time is spent simply finding the problematic commit.
-More information is in @ref{Regression tests}.
projects / lilypond.git / blobdiff