Yes, the release has not happened yet. That commit is just the penultimate step.

This is definitely the wrong place for it... but I noticed with the vet and godoc move that I had trouble "go get"ting them.

I have GOROOT in /usr/local/src/go and root owns that as it's put there in our dev builds by our bootstraps scripts.

I have GOPATH in /home/{user}/Dev/Go

One cannot go get as root from GOROOT for system install, and one cannot trivially go get in the user GOPATH either. The latter is due to vet and godoc needing permission against GOROOT.

If you sudo the go get within GOPATH, then that works from the GOROOT permissions point of view, but then (once you get past Mercurial freaking) the bits of GOPATH/pkg and GOPATH/src that relate to vet and godoc and owned by root... making any subsequent go get of say, the HTML parser, fail because it cannot write to the folder.

I ended up doing this as a user to go get vet and godoc within GOPATH:

    echo "[trusted]
    users = *
    groups = *
    " > ~/.hgrc
    sudo sh -c "export GOPATH=$GOPATH && export GOROOT=$GOROOT && export PATH=$PATH:$GOROOT/bin && go get -u code.google.com/p/go.tools/cmd/godoc"
    sudo sh -c "export GOPATH=$GOPATH && export GOROOT=$GOROOT && export PATH=$PATH:$GOROOT/bin && go get -u code.google.com/p/go.tools/cmd/vet"
    USER=$(whoami)
    GROUP=$(id -g -n $USER)
    sudo chown -R $USER:$GROUP $GOPATH

It works, but there is a better way, right?

Do the docs assume Go source installs are user specific?

What bug is that?

Beg your pardon, jumped the gun myself there. Misread a comment on the IRC channel: "unless there's some massive bug, I doubt we'll see the tip of the tree change"