Doc: CG - replace all references of Google Code

Documentation/contributor/issues.itexi

 Elu@c -*- coding: utf-8; mode: texinfo; -*-
 @node Issues
 @chapter Issues
 
 This chapter deals with defects, feature requests, and
 miscellaneous development tasks.
 
 @menu
 * Introduction to issues::
 * The Bug Squad::
@@ skipping 62 matching lines @@
 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.
 
 @enumerate
 
 @item
 Read every section of this chapter, @ref{Issues}.
 
 @item
-If you do not have one already, create a gmail account and send
-the email address to the @ref{Meisters, Bug Meister}.
+If you do not have one already, get an email account and send the
+address to the @ref{Meisters, Bug Meister}.
 
 @item
-Subscribe your gmail account to @code{bug-lilypond}.
+Subscribe your email account to @code{bug-lilypond}.
 
 @item
-Configure your google code account:
-
-@enumerate
-
-@item
-Wait until your gmail account is listed in:
+Create your own Sourceforge login (required for the Allura tracker):
 
 @example
-@uref{http://code.google.com/p/lilypond/people/list}
+@uref{https://sourceforge.net/p/testlilyissues/issues/}
 @end example
 
 @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
-Go to your @qq{Profile}, and select @qq{Settings}.
+Fill in your details as required.
 
 @item
-Scroll down to @qq{Issue change notification}, and make sure that
-you have @emph{selected} @qq{If I starred the issue}.
-
-@end enumerate
+When this account has been created, send your email address to
+@email{lilypond-devel@@gnu.org} asking to be given the appropriate
+permissions to create and edit tracker issues.

[Trevor Daniels, 2016/03/19 16:50:08]

It's not the email address we need but the SourgeForge Username.

[pkx166h, 2016/03/26 15:44:20]

Done - with a minor addition.

 
 @item
-Configure your email client:

[Trevor Daniels, 2016/03/19 16:50:08]

I think we need to keep this item and the following @enumerate.  Otherwise the
following sub-items don't make sense.

[pkx166h, 2016/03/26 15:44:20]

Yes I see. I took some more time to look over this subsection and have
re-organized it slightly so that it 'flows' more logically, I also noticed that
we ask the bu-squadee to send his request for Allura to lilypond-dev but
actually that would mean they would need to also subscribe to that mail list to
be allowed to send emails. As this is not a requirement for bug Squad work, I
changed this to 'send your SF user name to bug-lilypond instead - although that
would mean you (or Phil) would need to be on that list. I have assumed you both
are, but if you want to put this back (and require that they subscribe to dev as
well) let me know.

-
-@enumerate
-
-@item
-Any email sent with your gmail address in the @code{To:} or
+Any email sent with your 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}.
-
 @item
 Any other email either from, or CC'd to,
 
 @example
-lilypond@@googlecode.com
+testlilyissues-auto@@lists.sourceforge.net
 @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.
+You do @strong{not} need to  read these emails.  If you are curious,
+go ahead and read them later, but it not necessary for Bug Squad work.
 
 @item
 Any other email sent to (or CC'd to):
 
 @example
 bug-lilypond
 @end example
 
 @noindent
 should go into a separate @code{bug-current} folder.
 
 @end enumerate
 
-@end enumerate
-
 
 @node 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.
 
 Please use the email sorting described in @ref{Bug Squad setup}.
 This means that (as Bug Squad members) you will only ever respond
 to emails sent or CC'd to the @code{bug-lilypond} mailing list.
 
 
 @subsubheading Emails to you personally
 
 You are not expected to work on Bug Squad matters outside of your
 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 as of July 2015
 
 @example
 Monday: Federico Bruni
 Tuesday: Simon Albrecht
 Wednesday: Simon Albrecht
 Thursday: Colin Campbell
-Friday:
+Friday: Ralph Palmer
 Saturday: Colin Campbell
 Sunday:
 @end example
 
 
 @subsubheading Emails to @code{bug-answers}
 
 Some of these emails will be comments on issues that you added to
 the tracker.
 
@@ skipping 133 matching lines @@
 
 @subheading Regular maintenance
 
 After @strong{every release} (both stable and unstable):
 
 @itemize
 
 @item
 Issues to verify: go to
 
+@smallexample
+@uref{https://sourceforge.net/p/testlilyissues/issues/search/?q=status%3AFixed}
+@end smallexample
+
+(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 marked as 'Fixed' by a
+developer.  If the developer has done their job properly, the
+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
-@uref{http://code.google.com/p/lilypond/issues/list?can=7}
+Fixed_2_19_39
 @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 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:
+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
 been pushed into the code base.}  The developer should have put
 information similar to @qq{Pushed as as
@@ skipping 662 matching lines @@
 
 @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

[Trevor Daniels, 2016/03/26 23:09:37]

This is a large section to simply delete.  I realise much of it is not currently
relevant, but rather than just deleting it perhaps it would be better to replace
it with details of the current procedure, so that when the day comes (hopefully
not soon!) to appoint a new bug-meister he will have a source of reference for
our procedures.

[pkx166h, 2016/03/27 11:39:55]

Hello Trevor, 

I am not following you mean.

All I can see here is more additional information (lower down) - albeit using
the new Google code links - and a shuffle of one para further up than it was,
(in the section above).

?

[Trevor Daniels, 2016/03/28 20:37:37]

Hi James

Hhm, this is strange.  The large deleted section only appears when viewing the
delta from patch set 1, so maybe it's a misleading artifact.  And I've just
noticed it's all within @ignore brackets, so maybe it's less important than I
thought anyway.  I withdraw my comment; sorry for the noise.

Trevor

 
 @end ignore
 
 
 @node Summary of project status
 @section Summary of project status
 
 @subsubheading Project overview
 
-Grid view provides the best overview:
+Project activity
 
 @smallexample
-@uref{http://code.google.com/p/lilypond/issues/list?mode=grid&y=Priority&x=Type&cells=ids}
+@uref{https://sourceforge.net/projects/testlilyissues/}
 @end smallexample
 
 @subsubheading Hindering development
 
 These issues stop or slow development work:
 
 @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:Accepted%20AND%20_type:Maintainability}
 @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.
+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.
 
 @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:Accepted%20AND%20labels:Frog}
 @end smallexample
 
-@subsubheading Patches to review
+@subsubheading Patches currently in the Patch Review cycle
 
-Patches which have no @qq{obvious} problems:
+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.
 
 @example
-@uref{http://code.google.com/p/lilypond/issues/list?can=2&q=label:patch-review}
+http://philholmes.net/lilypond/allura/
 @end example
 
 
+@noindent
+New patches
 
+@smallexample
+@uref{https://sourceforge.net/p/testlilyissues/issues/search/?q=status%3AStarted+AND+_patch%3Anew}
+@end smallexample
+
+
+@noindent
+Patches under Review
+
+@smallexample
+@uref{https://sourceforge.net/p/testlilyissues/issues/search/?q=status%3AStarted+AND+_patch%3Areview}
+@end smallexample
+
+
+@noindent
+Patches on final Countdown
+
+@smallexample
+@uref{https://sourceforge.net/p/testlilyissues/issues/search/?q=status%3AStarted+AND+_patch%3Acountdown}
+@end smallexample
+
+
+@noindent
+Patches that can be pushed
+
+@smallexample
+@uref{https://sourceforge.net/p/testlilyissues/issues/search/?q=status%3AStarted+AND+_patch%3Apush}
+@end smallexample