Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
doc: clarify fetching Go 1.4 from git #25816
A decision seems to have been made to no longer provide version controlled 1.4.x source code for doing a clean Go bootstrap on macOS. Is this true? You need a special tarball? How should the the current state of affairs for source code bootstrapping be characterized?
I think the comment that kinda shook me was:
Currently to get close to a clean bootstrap you have to download a special tarball. A doc change was made to fix the bootstrap issue. But on my system that special version of 1.4.3 builds but doesn't pass tests. It will build 10.2 however.
What really gets me in the craw is the atavistic reversion to a tarball instead of using git and version control.
Yes, I know I could have used my existing Go 10.1 to compile 10.2. Is that what everyone else does now?
Perhaps the pain level of maintaining the 1.4 bootstrap has been reached? Maybe it is time to retire the 1.4 bootstrap and just use archived binaries of previous versions of Go? I think there is some risk and complexity with that approach too, but it's a valid approach, and I could live with it. Whatever the decision is, it should be an explicit decision, not something the team slumps into because no one wants to maintain the bootstrap anymore.
tl;dr version below.
Check to see if there is a newer bootstrap version. There is a 1.4.3. Get that. Build it. Same thing.
Look around, it's a High Sierra issue and Go issue 16352 seems to have the answers.
So now I need to download a tarball to bootstrap? That's what the doc says. Oh, they fixed it with a tarball and a doc change.
Download the tarball. Have some kind of issue but I update Xcode and all is OK. At least it builds this time but now it fails with a timezone issue.
Check that error out. It's a known issue because the timezone data changed and the test isn't fixed in the tarball.
I replace the `TestParseInLocation in the tarball with the one from 10.2 and it works.
Wow this was painful and when building 10.2 I still get an error on my machine.
which is also supposedly fixed but has been failing on my previous laptop even with 10.10. I will try to figure out what is going on with that. Maybe something to do with being a member of multiple groups? IDK. That's a different issue and I get the feeling it may be specific to my setup.
I suggest you read the bootstrapping instructions carefully. This is what they say:
See how it says to run
That said, it seems like your main complaint is that the bootstrapping tarball is just, well, a tarball called
better than having to
I think that another reason the bootstrap version is kept as a branch and not a tag is that it needs changes over time to keep building. So it is easiest to keep it a rolling release than to advance into versions like 1.4.12, especially when Go 1.4 hasn't been supported for more than two years now.
@tildeleb I can see that you got pretty frustrated. I think this is probably a documentation bug, though. Perhaps you could take a second look and suggest what doc changes might have helped. It is hard to see documentation issues without fresh eyes.
As to why I believe this to be only a documentation issue:
If you're not convinced that this is a documentation bug, I'd like to hear more--calmly, though, please. And to reiterate, doc fixes can be hard for those who are too close to the problem, so suggestions are welcome. Thanks.
First, I apologize if there was an attitude with how I worded the issue. I thought some more about it.
I understand the urge to classify this issue as a documentation issue. I think the best way to characterize this issue is a "mindset", "process", or user experience issue but part of it is a documentation issue.
Here's what irks me:
If the 1.4 changes are maintained at HEAD on a branch somewhere then why not just say that and give directions on how to get it?
How do I know the tests that fail are the "right" ones? I got the tarball version of 1.4 to pass "all.bash" by cherry picking the changes to a single test. I do understand that 1.4 is only used to build the compiler and that I was supposed to use "make.bash".
A little more explanation. tl;dr
To be honest I think part of the problem is just accumulated history and keeping up with changes to Go and the related doc over a very long period of time. Here's my first Go code:
It's been a long time since I built the bootstrap version of Go. Here is the version of 1.4 I was using:
I don't even know if I built it as a bootstrap or already had that version of it hanging around.
I actually did read the doc and managed to set the environment variable
We are not going to try to keep the tests passing on the 1.4 branch. We've discovered that there are many tests that effectively test the environment, and those tests break over time. This happens most obviously with tests that wind up testing timezones, as in the case you report. Keeping those tests working is pointless busywork. The documentation tells people to run
Similarly, I don't think we want to start making a new 1.4.n release each time we need to change something to keep up with changing systems. These changes are often highly system specific. Few people want or need to bootstrap from source; we must support these people, but we don't have to fire up a new release each time we make a system-specific change.
I think it would be fine if the docs were more clear about using git to get the branch, for example by providing the exact instructions. I think it's also fine to provide a tarball as we do, as that will be more convenient for most people. Anybody want to try to improve the docs here?
So while I'm sorry you ran into trouble, I do think that this is an issue to be addressed only be improving the documentation.
The 1.4 tests aren't necessarily supposed to pass. Disable them by default, to avoid the sort of unpleasant experience described in golang#25816. Change-Id: I763b8e52c8d16f4d9be14ad853df456652e51430