From: Graham Percival Date: Sun, 6 Jun 2010 17:31:07 +0000 (+0100) Subject: Doc: CG: more policy for Issues. X-Git-Tag: release/2.13.24-1~39 X-Git-Url: https://git.donarmstrong.com/?a=commitdiff_plain;h=dd3a5bd7f59ce88be7c811c6be6cbffb106639d8;p=lilypond.git Doc: CG: more policy for Issues. --- diff --git a/Documentation/contributor/issues.itexi b/Documentation/contributor/issues.itexi index aa489906ba..109d8bd7e1 100644 --- a/Documentation/contributor/issues.itexi +++ b/Documentation/contributor/issues.itexi @@ -6,17 +6,17 @@ This chapter deals with defects, feature requests, and miscellaneous development tasks. @menu -* Introduction to issues and the Bug Squad:: +* Introduction to issues:: +* Bug Squad checklists:: * Issue classification:: * Adding issues to the tracker:: -* Checking and verifying issues:: * Summary of project status:: * Finding the cause of a regression:: @end menu -@node Introduction to issues and the Bug Squad -@section Introduction to issues and the Bug Squad +@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 @@ -35,9 +35,23 @@ report contains enough information for developers, and checking that a developer's fix actually resolves the problem. -@subsubheading Email checklist +@node Bug Squad checklists +@section Bug Squad checklists -Every email to @code{bug-lilypond} should be handled within +We highly recommend that you configure your email client to put +messages from: + +@example +@@googlecode.com +@end example + +@noindent +into a separate folder than emails to @code{bug-lilypond}. + + +@subsubheading New emails to @code{bug-lilypond} + +Every new email to @code{bug-lilypond} should be handled within @strong{24 hours} in the first method which is applicable: @enumerate @@ -71,6 +85,104 @@ Accept the report as described in @end enumerate +@subheading Updates / discussion about issues + +We try to keep discussions about issues on the tracker, but +sometimes it spills over onto email. If discussion has ended with +no patch / resolution and at least @strong{3 days} have passed, +then either: + +@itemize + +@item +Summarize the recent discussion on the tracker, and add a link to +the original discussion. + +@item +Add the comment @qq{there was some technical discussion which I +could not understand}, and include a link to the original +discussion. + +We do not expect Bug Squad members to be programmers, or even to +be moderately-skilled users. Your job is to keep track of issue +reports; it is @emph{perfectly acceptable} to not understand +discussions between advanced users and/or developers. + +@end itemize + + +@subheading Regular maintenance + +After @strong{every release} (both stable and unstable): + +@itemize + +@item +Regression test comparison: if anything has changed suspiciously, +ask if it was deliberate. The official comparison is online, at: + +@example +@uref{http://lilypond.org/test/} +@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}). + +@example +@uref{http://code.google.com/p/lilypond/issues/list?can=7} +@end example + +@end itemize + +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 + +@subheading Irregular maintenance + +@warning{These tasks are a lot of work; gathering more volunteers +to help is definitely recommended. However, the Bug Squad should +handle the organization and training of new volunteers.} + +Once every year or two: + +@itemize + +@item +Checking all regtests: although we have a system for checking the +regtests between two versions, occasionally a bug will slip +through the cracks. It is therefore good to manually examine all +the regtests (compare the images to the text description). + +@item +Checking all issues: we try to mark each Issue @q{fixed} when we +fix it, but occasionally one or two issues will slip through the +cracks. It is therefore good to check all Issues. If you see the +same (broken) output as the initial report, then simply post a +@qq{Problem still exists in 2.x.y} message to the issue. + +@end itemize + + @node Issue classification @section Issue classification @@ -270,9 +382,9 @@ in to their google account before adding an item. @enumerate @item -Check if the issue falls into any previous category given on -@ref{Introduction to issues and the Bug Squad}. If in doubt, add -a new issue for a report. We would prefer to have some +Check if the issue falls into any previous category given on the +relevant checklists in @ref{Bug Squad checklists}. If in doubt, +add a new issue for a report. We would prefer to have some incorrectly-added issues rather than lose information that should have been added. @@ -293,6 +405,9 @@ email should contain a link to the issue you just added. @subsubheading Patch reminders +@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 @@ -316,64 +431,6 @@ was sent to multiple mailing lists (such as both @code{bugs} and email should contain a link to the issue you just added. -@node Checking and verifying issues -@section Checking and verifying issues - -After each release (both stable and unstable): - -@itemize - -@item -Regression test comparison: check the relevant version in -@uref{http://lilypond.org/test/}. - -@item -Issues to verify: -@uref{http://code.google.com/p/lilypond/issues/list?can=7}. - -@end itemize - -Once every 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 - -Once every year or two: (yes, these are large tasks; gathering -more volunteers to help is definitely recommended) - -@itemize - -@item -Checking all regtests: although we have a system for checking the -regtests between two versions, occasionally a bug will slip -through the cracks. It is therefore good to manually examine all -the regtests (compare the images to the text description). - -@item -Checking all issues: we try to mark each Issue @q{fixed} when we -fix it, but occasionally one or two issues will slip through the -cracks. It is therefore good to check all Issues. If you see the -same (broken) output as the initial report, then simply post a -@qq{Problem still exists in 2.x.y} message to the issue. - -@end itemize - @node Summary of project status @section Summary of project status