Planning Go 1.17

[Dmitri Shuralyov]

Hi gophers,

Go 1.16 is out (🎉!) and the tree is in the process of reopening for 1.17 development. Please see the tracking issue 44222 for the latest tree status, but as of this moment it's accepting early-in-cycle changes only; it will be opened up generally soon after that.

I'm aware there has been some planning done in advance for this cycle (for example, see this thread on register ABI and type params branches), but now is the time for the regular planning thread. Please use it to discuss your own plans for the 1.17 development cycle and coordinate.

(Reminder, this thread is for things you *PLAN TO DO YOURSELF*, not things you want other people to do.)

Thanks,

Dmitri

[Dmitri Shuralyov]

In the previous planning threads, we've asked everyone to take special care when working on risky changes. It seems to be working well, so please keep it up. As a reminder:

A change is risky if it can cause failures that are hard to diagnose (for example, changes to the runtime, GC, compiler, linker, TLS, other low-level component, or complex changes that need soak time under production workloads), or if it requires many CLs that are hard to revert (for example, large CLs or stacks of CLs).

If you’re planning on working on a change that may be risky, please do the following:

1. Unless the entire change is absolutely trivial to revert, protect the new code paths with a boolean flag, prefixed with "go117", that can be used to quickly toggle back to the old implementation. It can be a simple bool constant, for example, const go117UseEvenBetterLinker = true. Such flags must be findable by a simple grep for the string "go117". That way we can find them without missing any, and they can be cleaned up when we get to the Go 1.18 cycle.

2. Consider how you would answer the following questions for your change:
   How risky is the change you're planning to make?
   How will you know if it is working as intended?
   How much production testing does it need for you to be confident it is working as intended?
   At what time should the keep/revert decision be made?

3. Create a tracking issue in the Go 1.17 milestone with a release-blocker label. This issue will be used to track progress on the feature and make the final decision for Go 1.17.

If you have insights from past Go development cycles on how this practice can be improved further, we welcome your feedback. Its goal is to help everyone ship a robust release and minimize risk of unexpected delays. Thank you for your help!

[Daniel Martí]

I delievered on roughly half of the plans for 1.16; I finished most of
the tooling issues and CLs I wanted to get to, and also raised some new
proposals and issues that I hope to continue working on this cycle.

On the encoding/json front I did not muster the will to revisit the
fixes that got reverted for the 1.15 release, but they're still on my
radar. There are also a couple of fairly old json CLs I hope to finally
land this cycle.

I've been experimenting with dsnet and a few others on an encoding/json
re-implementation from the ground up. I plan to focus my json spare time
there for the foreseeable future.

As for recent non-trivial changes that I hope to land soon, I have a CL
to make devel version strings more meaningful (https://golang.org/cl/264938)
and another to make gofmt format files in parallel (https://golang.org/cl/284139).

It's also going to be an interesting cycle to follow the master branch,
with all the compiler refactors landing in master. Props to all of you
who have been working on those two huge branches. I'll do my small part
by continuing to use master regularly and nag when it breaks :)

That's it for me this cycle; I prefer to not have big plans, and instead
focus on smaller chunks of work depending on the interest and needs.
Though json and tools remain the general themes :)