Comment 1:

If we parallelize bootstrap, then there won't be need in caching on good machines. go
install -a std takes 6.5s on my machine, make.bash must not take significantly more.
Probably 10 seconds or so.

Comment 2:

Also you can take a look at how I cache build for benchmarks (grep for lastWorkdir or
something like this).

Comment 3:

Do we really want to parallelize bootstrap, though?
Seems like adding a lot of complexity to a fundamental part of our system, in exchange
for a minor gain that can be achieved by other means.

Comment 4:

Sometimes I run bootstrap like 100 per day, so that has value beyond builders.
Also parallel bootstrap is local complexity in exchange to system complexity.

Comment 5:

Labels changed: added builder.

@adg, I can't figure out the interface to the dashboard here.

The openbsd-amd64-gce56 builder is only building Go commits and not packages (you can see the blank cells at the bottom of https://build.golang.org), but these URLs don't give me any info:

http://build.golang.org/todo?builder=openbsd-amd64-gce56&kind=build-go-commit
http://build.golang.org/todo?builder=openbsd-amd64-gce56&kind=build-package

What is the URL to ask the daskboard what subrepo packages need to be built?

And now those URLs are returning data! I'm even more confused. You didn't push a new version, did you?

I didn't change anything.

Per discussion with @adg we're going to not modify the /todo handler, so we don't break the old-style builders.

The coordinator instead will learn which subrepos it needs to build based on the data from http://build.golang.org/?mode=json (which is to be done in #9493)

This is now fixed with the recent builder work.