Doc: CG - replace references of Google Code with Sourceforge Allura

[lilypond.git] / Documentation / contributor / issues.itexi

diff --git a/Documentation/contributor/issues.itexi b/Documentation/contributor/issues.itexi
index 7bea16493755889276220f35dc2aa15b7eb4586e..434ead511a139e1181b417f0cfb7997e4da18ae6 100644 (file)
--- a/Documentation/contributor/issues.itexi
+++ b/Documentation/contributor/issues.itexi
@@ -1,4 +1,4 @@
-@c -*- coding: utf-8; mode: texinfo; -*-
+Elu@c -*- coding: utf-8; mode: texinfo; -*-

 @node Issues
 @chapter Issues
 
 @node Issues
 @chapter Issues
 


@@ -7,9 +7,7 @@ miscellaneous development tasks.
 
 @menu
 * Introduction to 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::
 * Issue classification::
 * Adding issues to the tracker::
 * Patch handling::


@@ -20,151 +18,137 @@ miscellaneous development tasks.
 @node Introduction to issues
 @section Introduction to issues
 
 @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 The Bug Squad
+@section The Bug Squad

 
 

-@node Bug Squad overview
-@section Bug Squad overview
+@menu
+* Bug Squad setup::
+* Bug Squad checklists::
+@end menu

 
 

-The Bug Squad are volunteers who progress issue tracking using the
-Google Issue tracker at
+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:

 
 

-@example
-@uref{http://code.google.com/p/lilypond/issues/list}
-@end example
-
-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
 
 @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
 
 @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
 
 @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
-email folders names were chosen specifically to make them work if
-you sort your folders alphabetically.
+We highly recommend that you configure your email client to use some
+kind of sorting and filtering as this will significantly reduce and
+simplify your workload.  Suggested email folder names are mentioned
+below to work when sorted alphabetically.

 
 @enumerate
 
 @item
 
 @enumerate
 
 @item

-Read every section of this chapter, @ref{Issues}.
+Read every section of the @ref{Issues} chapter in this guide.

 
 @item
 
 @item

-If you do not have one already, create a gmail account and send
-the email address to the @ref{Meisters, Bug Meister}.
+Subscribe your email account to @code{bug-lilypond}.  See
+@uref{https://lists.gnu.org/mailman/listinfo/bug-lilypond}.

 
 @item
 
 @item

-Subscribe your gmail account to @code{bug-lilypond}.
+Send your email address to the @ref{Meisters, Bug Meister}.

 
 @item
 
 @item

-Configure your google code account:
+Create your own Sourceforge login (required for the Allura issue
+tracker):

 
 

-@enumerate
+@itemize

 
 @item
 
 @item

-Wait until your gmail account is listed in:
-
-@example
-@uref{http://code.google.com/p/lilypond/people/list}
-@end example
+Go to @uref{https://sourceforge.net/p/testlilyissues/issues/}

 
 @item
 
 @item

-Sign in to google code by clicking in the top-right corner of:
-
-@example
-@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/}.
+Click on 'Join' in the top-right corner.

 
 @item
 
 @item

-Go to your @qq{Profile}, and select @qq{Settings}.
+Fill in your details as required and click the @emph{Register} button to
+complete the registration.

 
 

-@item
-Scroll down to @qq{Issue change notification}, and make sure that
-you have @emph{selected} @qq{If I starred the issue}.
+@end itemize

 
 

-@end enumerate
+@item
+Send your Sourceforge @emph{username} (not your email address) to
+@email{bug-lilypond@@gnu.org} asking to be given appropriate permissions
+to either create, edit and comment on tracker issues.

 
 @item
 Configure your email client:
 
 
 @item
 Configure your email client:
 

-@enumerate
+@itemize

 
 @item
 
 @item

-Any email sent with your gmail address in the @code{To:} or
-@code{CC:} fields should go to a @code{bug-answers} folder.
-
-When setting up your filtering rules, be aware that Google Code
-might use different versions of your email address, such as ones
-ending in @code{@@googlemail.com} or @code{@@gmail.com}.
+Any email sent with your address in the @code{To:} or @code{CC:} fields
+should be configured to go into a @code{bug-answers} folder.

 
 @item
 
 @item

-Any other email either from, or CC'd to,
+Any email either @code{From:} or @code{CC:} to,

 
 @example
 
 @example

-lilypond@@googlecode.com
+testlilyissues-auto@@lists.sourceforge.net

 @end example
 
 @noindent
 @end example
 
 @noindent

-should go into a separate @code{bug-ignore} folder.  Alternately,
-you may automatically delete these emails.
-
-You will @strong{not read} these emails as part of your Bug Squad
-duties.  If you are curious, go ahead and read them later, but it
-does @strong{not} count as Bug Squad work.
+should be configured to go into a @code{bug-ignore} folder or,
+alternately, configure your email client to delete these automatically.
+You do @emph{not} need to read mails in the @code{bug-ignore} folder.
+If you are curious (and have time) then read them, but they are not
+necessary for Bug Squad work.

 
 @item
 
 @item

-Any other email sent to (or CC'd to):
+Any email sent @code{To:} or @code{CC:} to,

 
 @example
 bug-lilypond
 @end example
 
 @noindent
 
 @example
 bug-lilypond
 @end example
 
 @noindent

-should go into a separate @code{bug-current} folder.
+should be configured to go into a @code{bug-current} folder.

 
 

-@end enumerate
+@end itemize

 
 @end enumerate
 
 
 @node Bug Squad checklists
 
 @end enumerate
 
 
 @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.
 
 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.


@@ -183,16 +167,16 @@ please forward such emails to the @code{bug-lilypond} list so that
 the currently-active Bug Squad member(s) can handle the message.
 
 
 the currently-active Bug Squad member(s) can handle the message.
 
 

-@subsubheading Daily schedule
+@subsubheading Daily schedule as of July 2015

 
 @example
 
 @example

-Monday:    Colin H
-Tuesday:   Eluze
-Wednesday: Marek
-Thursday:  Ralph
-Friday:    Marek
-Saturday:  Mark
-Sunday:    Colin H
+Monday: Federico Bruni
+Tuesday: Simon Albrecht
+Wednesday: Simon Albrecht
+Thursday: Colin Campbell
+Friday: Ralph Palmer
+Saturday: Colin Campbell
+Sunday:

 @end example
 
 
 @end example
 
 


@@ -344,21 +328,26 @@ After @strong{every release} (both stable and unstable):
 @item
 Issues to verify: go to
 
 @item
 Issues to verify: go to
 

-@example
-@uref{http://code.google.com/p/lilypond/issues/list?can=7}
-@end example
+@smallexample
+@uref{https://sourceforge.net/p/testlilyissues/issues/search/?q=status%3AFixed}
+@end smallexample

 
 

-(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 the @qq{Open (Fixed)}
+button down the left-hand frame)

 
 

-You should see a list of Issues that have been claimed fixed by a
+You should see a list of Issues that have been marked as 'Fixed' by a

 developer.  If the developer has done their job properly, the
 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:
+Issue should have the @qq{Labels} field filled in with @qq{Fixed_x_y_z},
+where X is the major version, y the minor version and z the current
+release.
+
+@example
+Fixed_2_19_39
+@end example
+
+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
 
 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


@@ -820,7 +809,6 @@ email should contain a link to the issue you just added.
 @end enumerate
 
 
 @end enumerate
 
 

-

 @node Patch handling
 @section Patch handling
 
 @node Patch handling
 @section Patch handling
 


@@ -828,171 +816,87 @@ email should contain a link to the issue you just added.
 separate person handling this task.}
 
 For contributors/developers: follow the steps in
 separate person handling this task.}
 
 For contributors/developers: follow the steps in

-@ref{Commits and patches}, and @ref{Pushing to staging}.
-
-For people doing maintenance tasks: git-cl is adding issues, James
-is testing them, Colin is selecting them for countdowns, and
-Patchy is merging from staging to master.  In the coming weeks,
-these tasks will be more and more automated.
+@ref{Patches}, and @ref{Pushing to staging}.

 
 @ignore
 
 @ignore

-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.
-
-@end ignore
-@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
-message) on the webgit page:
-
-@example
-@uref{http://git.savannah.gnu.org/gitweb/?p=lilypond.git}
-@end example
+For people doing maintenance tasks: git-cl is adding issues, James
+is testing patches and managing the Patch countdown.  He also generally
+runs the scripts that merging to Staging (although other developers are
+available to do this task if required).

 @end ignore
 @end ignore

-@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.
-
-@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.
+@node Summary of project status
+@section Summary of project status

 
 

-@end itemize
+@subsubheading Project overview

 
 

+Project activity

 
 

-@subheading Patch Meister
+@smallexample
+@uref{https://sourceforge.net/projects/testlilyissues/}
+@end smallexample

 
 

-The Patch Meister will:
+@subsubheading Hindering development

 
 

-@itemize
+These issues stop or slow development work:

 
 

-@item
-send @qq{countdown} emails to
-@code{lilypond-devel} when patches appear to be ready.
+@smallexample
+@uref{https://sourceforge.net/p/testlilyissues/issues/search/?q=status:Accepted%20AND%20_type:Maintainability}
+@end smallexample

 
 

-@item
-send general requests to review patches, or even nasty requests to
-review patches.
+@subsubheading Easy tasks

 
 

-@item
-downgrade patches from @code{Patch-review} to
-@code{Patch-needs_work} as appropriate.
+Issues tagged with @code{Frog} indicates a task suitable for a
+relatively new contributor.  The time given is a quick (and probably
+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.

 
 

-@item
-downgrade patches from @code{Patch-needs_work} to
-@code{Patch-abandoned} if no actions have been taken in four
-weeks.
+@smallexample
+@uref{https://sourceforge.net/p/testlilyissues/issues/search/?q=status:Accepted%20AND%20labels:Frog}
+@end smallexample

 
 

-@end itemize
+@subsubheading Patches currently in the Patch Review cycle

 
 

-@end ignore
+Overview

 
 

+@c The following URL is provided by one of the Developers giving a much
+@c easier way to see all patches at all stages of the Review cycle in a
+@c single place.

 
 

-@node Summary of project status
-@section Summary of project status
+@example
+http://philholmes.net/lilypond/allura/
+@end example

 
 

-@subsubheading Project overview

 
 

-Grid view provides the best overview:
+@noindent
+New patches

 
 @smallexample
 
 @smallexample

-@uref{http://code.google.com/p/lilypond/issues/list?mode=grid&y=Priority&x=Type&cells=ids}
+@uref{https://sourceforge.net/p/testlilyissues/issues/search/?q=status%3AStarted+AND+_patch%3Anew}

 @end smallexample
 
 @end smallexample
 

-@subsubheading Hindering development

 
 

-These issues stop or slow development work:
+@noindent
+Patches under Review

 
 @smallexample
 
 @smallexample

-@uref{http://code.google.com/p/lilypond/issues/list?can=2&q=label:Maintainability}
+@uref{https://sourceforge.net/p/testlilyissues/issues/search/?q=status%3AStarted+AND+_patch%3Areview}

 @end smallexample
 
 @end smallexample
 

-@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.
+@noindent
+Patches on final Countdown

 
 @smallexample
 
 @smallexample

-@uref{http://code.google.com/p/lilypond/issues/list?can=2&q=label:Frog}
+@uref{https://sourceforge.net/p/testlilyissues/issues/search/?q=status%3AStarted+AND+_patch%3Acountdown}

 @end smallexample
 
 @end smallexample
 

-@subsubheading Patches to review
-
-Patches which have no @qq{obvious} problems:
-
-@example
-@uref{http://code.google.com/p/lilypond/issues/list?can=2&q=label:patch-review}
-@end example
-

 
 

+@noindent
+Patches that can be pushed

 
 

+@smallexample
+@uref{https://sourceforge.net/p/testlilyissues/issues/search/?q=status%3AStarted+AND+_patch%3Apush}
+@end smallexample