code review 89580043: all: use http://golang.org/(issue|change) throughout

all: use http://golang.org/(issue|change) throughout

Newer code appears to favor linking to an issue over
mentioning its number, so older code was modified to
match this.  Most links to code.google.com/p/...
were shortened to the new golang.org/... equivalents.

[rh, 2014-04-19 16:49:28]

Hello golang-codereviews@googlegroups.com,

I'd like you to review this change to
https://code.google.com/p/go

[minux1, 2014-04-19 18:23:10]

is this really necessary?

i don't want to change the gophertool at least, because it adds one more
redirection to links with no real benefits imho.

[rh, 2014-04-19 22:03:12]

On 2014/04/19 18:23:10, minux wrote:
> is this really necessary?
> 
> i don't want to change the gophertool at least, because it adds one more
> redirection to links with no real benefits imho.

Thank you for your review.

It is not necessary, but I feel it is beneficial.  It makes it easier to read
about related issues when reading through Go source code.  There are a lot of
changes, but the vast majority are in comments, so the risk seems minimal.  I
have removed the changes to gopher.js per your suggestion, to avoid the
redirection.

[r, 2014-04-20 17:50:17]

NOT LGTM

I prefer, as a human, to read "Fix for issue 2345" than "Fix for
http://golang.org/issue/2345". I don't want to read URLs in prose.

[rh, 2014-04-20 17:54:11]

On 2014/04/20 17:50:17, r wrote:
> NOT LGTM
> 
> I prefer, as a human, to read "Fix for issue 2345" than "Fix for
> http://golang.org/issue/2345%22. I don't want to read URLs in prose.

Thank you for the review.

Would a CL changing the existing uses of "Fix for http://golang.org/issue/2345"
to "Fix for issue 2345" be welcomed, or would it be preferred to just abandon
and leave all things as they are?

[r, 2014-04-21 00:07:06]

Let's let some others weigh in before taking any action.

-rob

[josharian, 2014-04-21 00:33:42]

My 2c: I'd rather not touch so many files at this stage of the
release, even if it is just comment changes.

After Go 1.3, I'd say ok, because it is helpful for new contributors to be
able to do the right thing by following local style, for any value of
"local".

-josh


On Sunday, April 20, 2014, Rob Pike <r@golang.org> wrote:

> Let's let some others weigh in before taking any action.
>
> -rob
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-codereviews" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-codereviews+unsubscribe@googlegroups.com <javascript:;>.
> For more options, visit https://groups.google.com/d/optout.
>

[bradfitz, 2014-04-21 00:40:45]

Agree. It's time for things to chill.
 On Apr 20, 2014 5:33 PM, "Josh Bleecher Snyder" <josharian@gmail.com>
wrote:

> My 2c: I'd rather not touch so many files at this stage of the
> release, even if it is just comment changes.
>
> After Go 1.3, I'd say ok, because it is helpful for new contributors to be
> able to do the right thing by following local style, for any value of
> "local".
>
> -josh
>
>
> On Sunday, April 20, 2014, Rob Pike <r@golang.org> wrote:
>
>> Let's let some others weigh in before taking any action.
>>
>> -rob
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "golang-codereviews" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to golang-codereviews+unsubscribe@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>  --
> You received this message because you are subscribed to the Google Groups
> "golang-codereviews" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-codereviews+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

[r, 2014-04-21 00:51:00]

SGTM

[rh, 2014-04-21 00:58:55]

On 2014/04/21 00:51:00, r wrote:
> SGTM

Thanks, all, for the thoughts.  I'll wait until after 1.3.