If this is done, and one runs godoc -http=localhost:6060, what do you expect/want to show up at http://localhost:6060/blog/? Currently, it shows the blog.

I think redirect to https://blog.golang.org for the lastest blog is much more appropriate .

I can't seem to find an issue for it now, but I'm pretty sure there have been thoughts/discussions about moving the golang.org website functionality out of the main repository into a sub-repository or so. This issue seems to be somewhat related to that.

(sigh my poor English
I've did the search on Github no move to subrepos issues AFAIK

Most of the user just don't need those images and blog content for their build machine or server.
Those blog contents will grow to huge size if every post is looks alike.
https://blog.golang.org/community-outreach-working-group

If they want to check out blog, they will find a way.

Growth rate of the blog is +~2MB/Year. Deleting merits a 20MB reduction with drawbacks: content locality loss. I use the self-hosted blog when demonstrating how easy it is to run a web server in Go. Perhaps I represent a small percentile of Go users, but its hard to ignore convention and convenience.

Just started managing go for our servers here and also perplexed why the "binary distribution" contains the blog and all its contents. I don't need or want someone else's (or any, really) website on my build slaves. Also, and slightly off subject for the specific topic of blog, why does the binary package contain a "src" dir with 50+mb of source. If this is for compilations/includes, should it not be in "lib"... which is another thing, the lib/ dir exists but only has "time" in it. I think the whole golang "binary" distribution packaging needs to be reevaluated/updated.

One potential compromise is we could ship all the files in the source tarball, but strip non-critical files from the binary downloads.

/cc @andybons

Ideally we’d separate out (most of) the content from golang.org from the binary distribution and leave godoc -http as something akin to what godoc.org looks like (web-based documentation and that’s it).

As we redo our website in the coming months, it will become less and less tenable to have a mirror of golang.org packaged with our primary distribution like we do now.

If users want to be able to run golang.org offline, then they could grab the repo that the website will eventually live in and run it locally.

Repurposing this to cover all web site assets for now. @shurcooL if you find that other bug please dupe it into that one. Thanks 👍

I think there is a disconnect somewhere. When I download a binary package of a programming language/compiler, I do not expect, nor want, someone's blog app, especially one complete with content, the mirror for the language's web site, or any other non-related program. I also do not expect to get the source code, as that would be in a "source" package. I expect to get a package with pre-compiled programs that allow me to run golang based programs, and compile golang sources into go apps. Not much more than that. Source code belongs in a source package downloaded separate (which go already has, so I really don't know why its packaged again in the binary). Examples and tutorials belong in a tutorial/example package. If Blog is how documentation is done for golang, or if golang is trying to make a major shift from the normal for how things are packaged, that needs to be presented as such in the Readme, on the website, in the install instructions, etc. It is not at all intuitive. This ticket has changed titles and purposes so many times in the comment flow it appears my comments probably no longer even matter, I will open a new issue.

@tmack0,

When I download a binary package of a programming language/compiler, I do not expect, nor want, someone's blog app, especially one complete with content, the mirror for the language's web site, or any other non-related program.

Some history: we've always shipped the "godoc" binary with Go, as is the main (and original) way to browse package documentation, both via the command line and via the browser. We've shipped that with Go since before there was even a $GOPATH, and it was a great developer tool for people to look up APIs. It was great when I was on airplanes without connectivity, to be able to browse localhost and read docs.

And it just so happened that golang.org was served by godoc.

There are plans to split the website into two halves: the package docs ("godoc") and the rest of the site (blob, etc). But that hasn't happened yet.

Source code belongs in a source package downloaded separate (which go already has, so I really don't know why its packaged again in the binary).

The cmd/go binary ("go install") etc uses the source code of the standard library on disk when you compile a binary. (but we also ship pre-built cached object files, so in practice they're not used. But if you tweak them, they're used. At least in Go 1.10.) It's true that we probably don't need to ship the source code to the compiler or linker or other "package main" things that aren't importable.

I've marked this as needing a decision. The @golang/proposal-review group will discuss in an upcoming meeting.

Thanks for the history. I agree offline docs are useful, though a simple Readme in the base dir of the "blog" folder explaining what it is (or changing the folder name to something like godoc) might be helpful. When I see files like "upcoming-google-io-go-events.article" I do not think "coding docs" though, which is what I assume is the website split you mention. Thanks!

@tmack0 there's a wiki page, at least: https://github.com/golang/go/wiki/FileTreeDocumentation

Change https://golang.org/cl/130575 mentions this issue: cmd/release: remove /blog from the releases