The Go 1.14 Release Candidate 1 has been in testing since Feb 5, and there are now no more release blocking issues that need to be investigated or resolved. We are planning to make the final Go 1.14 release early next week.
The Go 1.15 development tree will open soon on the master branch. As we have done with previous releases, we will first open the tree for changes that need to be made early in the cycle, and soon after that, more generally for all changes. We will provide information about the exact dates in this thread, please read on.
The release cycle document states “if a release is delayed, so is work on the next release.” The 1.14 release cycle is behind schedule, which cuts the development cycle of 1.15 shorter for everyone. This is unfortunate, but it was necessary to ensure known regressions in 1.14 could be investigated and resolved.
We on the Go release team (Alex, Carlos, and Dmitri) want to start taking steps now to reduce the chances of this pattern repeating itself in the upcoming 1.15 cycle. As part of that, we are making the following requests for all Go developers who will be submitting changes once the tree opens up:
Risky Changes
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:
Unless the entire change is absolutely trivial to revert, protect the new code paths with a boolean flag, prefixed with “go115”, that can be used to quickly toggle back to the old implementation. It can be a simple bool constant, for example, const go115UseNewLinker = true. The flag *must be findable* by a simple grep for the string “go115”, so that we can find and clean up all such flags when we get to the Go 1.16 cycle.
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?
Create a tracking issue with Go 1.15 milestone and release-blocker label using the golang.org/s/riskychange issue template. This issue will be used to track progress on the feature and make the final decision for Go 1.15.
Revert Sooner
When a change that landed on master results in a confirmed failure or unintended behavior change, we ask everyone to revert that change sooner, instead of letting it stay merged. For example, if we learn that a change in unspecified behavior of a function like url.Parse causes breakage, then it is better to roll back while thinking about how to address the issue.
This helps ensure master is more stable, making it easier for people who are developing other changes.
Freeze Exceptions
Any exceptions to the freeze must be communicated to and explicitly approved by the Go release team before the freeze. If you’d like to request an exception, please start a thread on golang-dev. We will address any requests on a case-by-case basis with a strong preference for not permitting changes after the freeze.
Changes that are not in line will be reverted on master and asked to be re-sent during next cycle.
Check build.golang.org Before Submitting
Before starting to submit your CL or a stack of CLs, please check that the tip is green at https://build.golang.org. If there is a widespread test failure, please wait, or better, help with efforts to diagnose and fix the failure.
We are making these requests with the goal of making the 1.15 cycle more predictable, and helping keep the tree in a healthier state throughout the development cycle. Thank you for the hard work everyone does to ensure each Go release is as good as it can be; it is really appreciated.
With the above requests in mind, we plan to open the tree for changes that should land early-in-cycle later today (Feb 19). We’ll send another email announcing that shortly. If your change can wait a few more days, please hold off until we open the tree generally on Friday (Feb 21).
In the meantime, please feel free to use this thread to share and discuss any work you’re planning to do or would like to do for Go 1.15.
--
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-dev/CA%2BON-PFgRYRHAMNpEcG1fRqmkZSxKfON6HWdiF3K0ntDh5hkkA%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-dev/CAFAcib_Co4QySxSPJwbJkoFUWzDaswaNMsQRyroPO-33__T9mQ%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-dev/CAFAcib_Co4QySxSPJwbJkoFUWzDaswaNMsQRyroPO-33__T9mQ%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-dev/CAHOpXeUhWgHUjrzgWbHzAjR78R229d2w1E3SZcfofRoEx%2BaT%2BA%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-dev/CAFAcib_JdM3yoU_j7KowAMTRqHezOeCqzwtNA9zy1bJsi_cx6A%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-dev/CAFAcib_JdM3yoU_j7KowAMTRqHezOeCqzwtNA9zy1bJsi_cx6A%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-dev/CA%2BUr55HrsZ-5rgYOKX5PW1ge13Lebvzzr%3Dq%2Bwi87ijdm4AmAqw%40mail.gmail.com.
I want to second both of Austin's emails and add a few additional thoughts.
I suspect (but can't prove) that the most problematic cases for
release timeliness aren't the ones that immediately break a builder;
we can just revert those. And I suspect (but can't prove) that the
most problematic cases for release timeliness often aren't the
obviously high risk changes, in part because the authors of obviously
high risk changes tend to take extra time and care testing them and
providing mitigation strategies.
I suspect that the most problematic cases are those that seem safe
and/or very well tested, yet which cause subtle and/or rare bugs,
often due to unexpected interactions with other moving parts. And I'm
not sure that we have a great track record at predicting those (which
is not to say we shouldn't try). And I'm not sure that the existence
of gates in these cases necessarily buys us that much: We had a gate
for signal-based preemption, but still lost a bunch of time
discovering and working around a kernel bug. So it's not obvious to me
that an emphasis on gating is going to have a good ROI.
Here are two additional (possibly unpopular) suggestions for different
things that we could try this cycle. (I often wish mailing lists had
emoji response counters, but in this case, I'm probably better off
without!) Maybe they'll spark other ideas...
(1) We could switch to a different set of Gerrit permissions during
the freeze, on the first day, such that only a small handful of people
can +2 or submit changes. It'd no doubt be painful at first, but
taking the reins much more firmly during the freeze will strongly
encourage us to go into the freeze in better shape.
(2) Issue an alpha release the day the freeze begins, rain or shine.
One reason is that it would encourage getting API feedback and finding
obvious issues (like backwards incompatibility) sooner. The second and
more important reason is to signal that the tree needs to be stable
going into the freeze.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-dev/CAFAcib9%3Dp1G%3D-D%3D-GVkFEu-XATEkryU4vFxdTav0eTr1U0FZ-A%40mail.gmail.com.
I suspect that the most problematic cases are those that seem safe
and/or very well tested, yet which cause subtle and/or rare bugs,
often due to unexpected interactions with other moving parts. And I'm
not sure that we have a great track record at predicting those (which
is not to say we shouldn't try). And I'm not sure that the existence
of gates in these cases necessarily buys us that much: We had a gate
for signal-based preemption, but still lost a bunch of time
discovering and working around a kernel bug. So it's not obvious to me
that an emphasis on gating is going to have a good ROI.
As to the new linker, will the output be byte-for-byte identical, or
are there other changes as well? If the output is identical, then
there's lots of additional benefit available with the "cp -r"
strategy: for a while, cmd/go could run both and report any
mismatches. I believe Russ did this during the c2go transition to good
effect, and I did it locally during my concurrent compilation work.
-josh
P.S. On a personal note, you may have noticed that I've been
submitting my changes a few at a time (depending on their exact
contents), to ensure that the dashboard is green before continuing.
This is my usual practice when I have lots of changes to submit.
> On Feb 20, 2020, at 3:18 PM, 'Austin Clements' via golang-dev <golan...@googlegroups.com> wrote:
>
> I think the "cp -r" technique to gate the linker is actually pretty reasonable. You have a good point about bug fixes, but risk mitigation doesn't come without a cost. It's an interesting question, though: when we merge in the new linker, the intent is to switch to it then, so maybe we stop fixing bugs in the old linker at that point? These gating flags are *not* meant to be knobs, they're meant to be "in case of emergency, break glass."
If the unit and regression tests don't catch catastrophic breakages like the ones feared here, why have them? This is what they're for, and the Go compiler has a pretty good set of tests as things go. At some point, especially for something like this, you need to be able to rely on the tooling built up over many years.
--
I have a question about the ABI change that has been discussed for the past few releases related to parameter and return value passing in registers instead of storage. I have not seen that mentioned recently, is that still in plan? I see that as a big performance improvement on ppc64/ppc64le and my understanding is for arm64 too.
(These are things you *PLAN TO DO YOURSELF*, not things you want other people to do.)