x/build: improve ability to look up current Go tree status ("open for development" or "frozen")

[dmitshur]

The Go tree regularly goes from "open for development" to "frozen for release" states, with 2 release cycles or 4 state transitions per year. During early tree reopening, there are some additional but minor nuances (e.g., "a sequence of early in cycle CLs is in the process of landing", "open for fix/stabilization CLs only for now").

These tree state transitions follow a predictable timeline, and we communicate important state transitions to the golang-dev mailing list, as well as "freeze is coming in N weeks" reminders. We've started using tracking issues to coordinate the tree reopening sequences, and those issues have a heading at the top with the latest state, but of course only it's actively updated only while tree reopening is still in progress and doesn't reflect the global latest state.

This is a tracking issue for some sort of dashboard that can reliably be kept updated and serve as a more convenient place to see whether the Go tree is open for development or frozen. (For example, something like https://chromiumdash.appspot.com/schedule in general, though it doesn't have to be as comprehensive.)

CC @golang/release.

[seankhliao]

i've seen projects just use a pinned issue in github which is highly visible for most people
(and a separate pinned issue for expectations on issue tracker interactions).

[dmitshur]

We already have some dashboards at https://dev.golang.org/, including https://dev.golang.org/release, that can be candidates for this. Another idea to explore is whether we could also mirror the tree status to Gerrit. For example, some other Gerrit instances have a 'Tree Status' UI chip configured:

The meaning of how "tree status" is used there is not the same as our 6-month major release cycle, but it might be possible to adapt to our needs. This needs some exploration.

[dmitshur]

@seankhliao Thanks, that's a good idea to consider too. It sounds quite a bit simpler at a glance, though we'd still want to make sure we're able to maintain it to always be up to date (either manually or with tooling). There's a limit of maximum 3 pinned issues to take into account, but perhaps allocating 1 of 3 to a permanently pinned issue is fine.

[gabyhelp]

Related Issues

• x/build/dashboard: enable/trigger build tracking for release-branch.go1.4 through go1.10 #38473 (closed)

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}