x/net/trace: use std context package

[gyuho]

Can we have context here https://github.com/golang/net/blob/master/trace/trace.go#L80?

This golang/time@c06e80d happened. Would the same change in trace break anything?

It's one of our sub-dependency and would like to know when this would happen :)

Thanks in advance!

[gopherbot]

CL https://golang.org/cl/41290 mentions this issue.

[dfawley]

This is a cascading problem. grpc-go is now broken since this package is a dependency of ours and we support Go 1.6. We are blocked on deprecating 1.6 and updating our imports until generated proto files use the standard context package. AppEngine only supports Go1.6, so I believe the proto compiler can't be changed until that is updated.

Is it possible to revert these context changes and hold off on them until Go1.6 is less widely used?

[bradfitz]

@dfawley, where is the grpc-go breakage? Got some URLs?

[dfawley]

Our tests only run on PRs and merges, so the main page doesn't show this breakage. Here's an example from an in-progress PR:

https://travis-ci.org/grpc/grpc-go/jobs/224274230#L215

[broady]

+1 on being affected by breakage. This breaks Google Cloud client libraries using gRPC on App Engine standard, which is stuck on Go 1.6.

[bradfitz]

It's been 14 months since Go 1.6. App Engine can't get another release out? Is that really what this is all about?

Go's policy is that we only test and maintain the past two releases. I could add some build tag chicanery into x/net/trace, but our builders aren't testing 1.6 anymore. I don't want to revert the change. We want to make forward progress on cleanups and other people want us to use std context.

Let me see what I can do.

[bradfitz]

https://go-review.googlesource.com/c/41413/

[scottma]

yak, getting this error now after this change .

golang.org/x/net/trace/trace.go:67: can't find import: "context"