]> git.donarmstrong.com Git - lilypond.git/commitdiff
Updates Bug Squad instructions in CG
authorPhil Holmes <mail@philholmes.net>
Wed, 15 Feb 2012 14:30:18 +0000 (14:30 +0000)
committerPhil Holmes <mail@philholmes.net>
Wed, 15 Feb 2012 14:34:23 +0000 (14:34 +0000)
Documentation/contributor/issues.itexi

index 2316f95855d30eebde70d21afd1c44797b7f5640..19509f1e52d03584505ea565cfdbceeddef81001 100644 (file)
@@ -7,6 +7,7 @@ miscellaneous development tasks.
 
 @menu
 * Introduction to issues::
 
 @menu
 * Introduction to issues::
+* Bug Squad overview::
 * Bug Squad setup::
 * Bug Squad checklists::
 * Issue classification::
 * Bug Squad setup::
 * Bug Squad checklists::
 * Issue classification::
@@ -38,6 +39,35 @@ that a developer's fix actually resolves the problem.
 New volunteers for the Bug Squad should contact the
 @ref{Meisters, Bug Meister}.
 
 New volunteers for the Bug Squad should contact the
 @ref{Meisters, Bug Meister}.
 
+@node Bug Squad overview
+@section Bug Squad overview
+
+The Bug Squad are volunteers who progress issue tracking using the
+Google Issue tracker at
+
+@example
+@uref{http://code.google.com/p/lilypond/issues/list}
+@end example
+
+Bug Squad members have 2 primary responsiblities:
+
+@enumerate
+
+@item
+Monitoring the LilyPond Bugs mailing list and adding to the
+tracker any new issues reported there.
+
+@item
+Verifying issues that are claimed fixed by a developer, to ensure
+that the fix works, and is actually in the code base.
+
+@end enumerate
+
+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.
+
+All of this is explained in more detail in the following sections.
 
 @node Bug Squad setup
 @section Bug Squad setup
 
 @node Bug Squad setup
 @section Bug Squad setup
@@ -158,10 +188,10 @@ the currently-active Bug Squad member(s) can handle the message.
 @example
 Monday:    Ralph
 Tuesday:   Eluze
 @example
 Monday:    Ralph
 Tuesday:   Eluze
-Wednesday: Brett
+Wednesday: Marek
 Thursday:  Colin Hall (disambiguation here)
 Friday:    Marek
 Thursday:  Colin Hall (disambiguation here)
 Friday:    Marek
-Saturday:  Brett
+Saturday:  James
 Sunday:    Phil
 @end example
 
 Sunday:    Phil
 @end example
 
@@ -312,19 +342,28 @@ After @strong{every release} (both stable and unstable):
 @itemize
 
 @item
 @itemize
 
 @item
-Issues to verify: try to reproduce the bug with the latest
-officially released version (not one you've built yourself from
-source); if the bug is no longer there, mark the
-issue @qq{Verified} (i.e. @qq{the fix has been verified to work}).
-
-The list of items to verify is here:
+Issues to verify: go to
 
 @example
 @uref{http://code.google.com/p/lilypond/issues/list?can=7}
 @end example
 
 
 @example
 @uref{http://code.google.com/p/lilypond/issues/list?can=7}
 @end example
 
-You can also generate this list by selecting @qq{Issues to verify}
-from the drop-down list next to the search box.
+(You can also generate this list by selecting
+@qq{Issues to verify} from the drop-down list next to the search
+box.)
+
+You should see a list of Issues that have been claimed fixed by a
+developer.  If the developer has done their job properly, the
+Issue should have a tag @qq{Fixed_mm_MM_ss}, where mm is
+the major version, MM the minor version and ss the current
+release.  This will help you work out which you can verify - do
+not verify any Issues where the claimed fixed build is not yet
+released.  Work your way through these as follows:
+
+If the Issue refers to a bug, try to reproduce the bug with the latest
+officially released version (not one you've built yourself from
+source); if the bug is no longer there, mark the
+issue @qq{Verified} (i.e. @qq{the fix has been verified to work}).
 
 Quite a few of these will be issues tracking patches.  @strong{You
 do not have to prove these patches work - simply that they have
 
 Quite a few of these will be issues tracking patches.  @strong{You
 do not have to prove these patches work - simply that they have
@@ -345,13 +384,25 @@ finding these is to enter the committish at the following address:
 @uref{http://philholmes.net/lilypond/git/}
 @end example
 
 @uref{http://philholmes.net/lilypond/git/}
 @end example
 
+The Issue tracker also requires that any issues labelled as
+@qq{Duplicate} are also verified.  Check that the linked issue is
+a duplicate and verify the issue.
+
 A few (approximately 10%) of the fixed issues relate to the
 build system or fundamental architecture changes; there is no way
 for you to verify these.  Leave those issues alone; somebody else
 will handle them.
 
 @item
 A few (approximately 10%) of the fixed issues relate to the
 build system or fundamental architecture changes; there is no way
 for you to verify these.  Leave those issues alone; somebody else
 will handle them.
 
 @item
-Regression test comparison: if anything has changed suspiciously,
+The official regression test comparison is online at:
+
+@c NOTE: leave this here.  In this case, it's worth duplicating
+@c       the link.  -gp
+@example
+@uref{http://lilypond.org/test/}
+@end example
+
+If anything has changed suspiciously,
 ask if it was deliberate.  If the text output from LilyPond (the
 logfile) changes, the differences will be displayed with a +
 before text added to the logfile and - before any text removed
 ask if it was deliberate.  If the text output from LilyPond (the
 logfile) changes, the differences will be displayed with a +
 before text added to the logfile and - before any text removed
@@ -362,14 +413,6 @@ regtests are created. @code{test-output-distance.ly} creates
 randomly spaced notes and will always have different output if the
 regtest checker is working.
 
 randomly spaced notes and will always have different output if the
 regtest checker is working.
 
-The official comparison is online, at:
-
-@c NOTE: leave this here.  In this case, it's worth duplicating
-@c       the link.  -gp
-@example
-@uref{http://lilypond.org/test/}
-@end example
-
 More information is available from in
 @ref{Precompiled regression tests}.
 
 More information is available from in
 @ref{Precompiled regression tests}.
 
@@ -481,8 +524,9 @@ The issue's Type should be the first relevant item in this list.
 
 @item
 Type-Critical: normally a regression
 
 @item
 Type-Critical: normally a regression
-against a previous stable version or a regression against a fix
-developed for this version. This does not apply where the
+against the current stable version or the previous stable version.
+Alternatively, a regression against a fix developed for the
+current version. This does not apply where the
 @qq{regression} occurred because a feature was removed
 deliberately - this is not a bug.
 
 @qq{regression} occurred because a feature was removed
 deliberately - this is not a bug.
 
@@ -519,6 +563,10 @@ Type-Enhancement: a feature request for the core program.  The
 distinction between enhancement and defect isn't extremely clear;
 when in doubt, mark it as enhancement.
 
 distinction between enhancement and defect isn't extremely clear;
 when in doubt, mark it as enhancement.
 
+@item
+Type-Patch: tracking a patch on Rietveld.  Bug squad should not
+need to use this label.
+
 @item
 Type-Other: anything else.
 
 @item
 Type-Other: anything else.
 
@@ -576,10 +624,11 @@ be downgraded from Priority-Critical by one of the programmers.
 
 Issues that only affect specific operating systems.
 
 
 Issues that only affect specific operating systems.
 
-@subheading Patch (optional)
+@subheading Patch label (optional)
 
 
-Normal Bug Squad members should not add or modify Patch issues;
-leave them to the Patch Meister.
+Normal Bug Squad members should not add or modify Patch issues
+except to verify them; for all other Patch work, leave them to the
+Patch Meister.
 
 @itemize
 
 
 @itemize
 
@@ -605,6 +654,12 @@ 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).
 
 @code{patch-new} (for normal contributors) or @code{patch-review}
 (for developers who are very confident about their patch).
 
+@item
+Patch-countdown: final call for any patch problems
+
+@item
+Patch-push: patch has passed the countdown and should be pushed.
+
 @item
 Patch-abandoned: the author has not responded to review comments
 for a few months.
 @item
 Patch-abandoned: the author has not responded to review comments
 for a few months.
@@ -618,11 +673,11 @@ Other labels:
 @itemize
 
 @item
 @itemize
 
 @item
-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.
+Regression: it used to work intentionally in the current
+stable release or the previous 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, please adopt
 the following process:
 
 To help decide whether the change is a regression, please adopt
 the following process:
@@ -672,7 +727,7 @@ Performance: performance issue.
 
 If you particularly want to add a label not in the list, go
 ahead, but this is not recommended, except when an issue is marked
 
 If you particularly want to add a label not in the list, go
 ahead, but this is not recommended, except when an issue is marked
-as fixed.  In this case it should be labeled fixed_mm_MM_ss,
+as fixed.  In this case it should be labeled Fixed_mm_MM_ss,
 where mm is major version, MM minor version and ss current
 release.
 
 where mm is major version, MM minor version and ss current
 release.
 
@@ -699,7 +754,7 @@ have been added.
 @item
 Add the issue and classify it according to the guidelines in
 @ref{Issue classification}.  In particular, the item should have
 @item
 Add the issue and classify it according to the guidelines in
 @ref{Issue classification}.  In particular, the item should have
-@code{Status}, @code{Type-}, and @code{Priority-} labels.
+@code{Status} and @code{Type-} labels.
 
 Include output with the first applicable method:
 
 
 Include output with the first applicable method:
 
@@ -732,7 +787,10 @@ lilypond --png bug.ly
 @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
 @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
+
+@smallexample
 @uref{https://raw.github.com/gperciva/lilypond-extra/master/bug-squad/trimtagline.sh}
 @uref{https://raw.github.com/gperciva/lilypond-extra/master/bug-squad/trimtagline.sh}
+@end smallexample
 
 @example
 trimtagline.sh bug.ly
 
 @example
 trimtagline.sh bug.ly