vendor, cmd/vendor: not clean on master

[dmitshur]

On latest master branch right now, the src/vendor directory is not clean. Its contents do not correspond 1:1 to the versions specified by the src/go.mod file.

Following the steps in src/README.vendor results in a non-zero diff:

go $ go version
go version devel +b13ce14c4a Tue Jan 28 20:26:36 2020 +0000 darwin/amd64
go $ cd src
src $ go mod tidy
src $ go mod vendor
src $ git status
On branch master
Your branch is up to date with 'origin/master'.

Changes not staged for commit:
  (use "git add/rm <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
	deleted:    vendor/golang.org/x/sys/cpu/cpu_riscv64.go

no changes added to commit (use "git add" and/or "git commit -a")

This is due to recent commits such as CL 216260, CL 216261, CL 216262 that are related to riscv64.

This makes it difficult and error prone to make changes to versions in src/go.mod, because the end result includes unexpected changes. See discussion in CL 216680.

If it's reasonable to resolve this, I don't think we should release Go 1.14 with a vendor directory that isn't clean, so tentatively marking this as release-blocker, but open to discussion.

/cc @4a6f656c @FiloSottile @golang/osp-team

[bcmills]

If there are other x/sys changes that we don't want to fold in at this point, one low-risk option would be to commit an x/sys branch that is the same as the current commit but adds the new risc-v file, then update to that commit.

[bcmills]

I noticed today that src/cmd/vendor is not clean either. (It includes changes in both x/sys and x/tools).

[dmitshur]

/cc @bcmills Do you think we should block Go 1.14 RC 1 on this? This is one of the potential blockers we are reviewing in the release meeting.

[bcmills]

I think it is important to at least decide how we will address this issue before we release RC1.

There appear to have been a large number of changes in x/sys/cpu and x/sys/unix in particular since those dependencies were last updated in the main repo.

The options that I see are:

1. Release Go 1.14 with non-clean vendor directories.

2. Upgrade the dependencies in question to some commit that covers the changed files (golang.org/x/sys v0.0.0-20200106114638-5f8ca72cd632 for CL 213397 and golang.org/x/tools v0.0.0-20200124162111-628e9aa307e6 for CL 216337).

3. Publish minimal patches in an off-master branch to the sys and tools repos and update the std and cmd dependencies to point to the patched commits.

I don't particularly like option (1). Option (2) seems cleanest from a process perspective, but option (3) seems less risky.

I think only option (2) would need to gate an RC.

[dmitshur]

Thanks @bcmills.

If we release Go 1.14 with non-clean vendor directories, it will have an effect on all future Go 1.14.x minor releases (and security releases). It will increase the difficulty and risk when backporting future fixes to the release-branch.go1.14 branch of the main Go repo.

We'll either need to resolve this issue soon after releasing Go 1.14 (before Go 1.14.1, etc.), or bear that cost for the rest of the time that Go 1.14 release is supported (at least 1 year). If we're going to have to fix it anyway, it seems better and easier to do so before releasing Go 1.14.

As a result, I believe we should not go with option 1.

[bcmills]

Thinking about future backports, we will probably want a release-branch.go1.14 for the x/sys and x/tools repos anyway. That would fit pretty naturally with option (3), where the off-master branch is simply release-branch.go1.14.

(It's unfortunate to cut the release branch from such old base commits, but it seems a bit late to correct that particular mistake now.)

[FiloSottile]

I agree that this close to the RC the best option is (2) with a new release branch.

That's what x/ repo release branches are for anyway, IMHO. See #36882.

[gopherbot]

Change https://golang.org/cl/217103 mentions this issue: golang.org/x/sys: update to v0.0.0-20200106114638-5f8ca72cd632