FAQ
Hi,

Thanks for all the work getting Go 1.6 out the door. It's a great release.
I've been using the http/2 support for a month or two and it's great.

Today I was caught off guard by a change between Go 1.6 rc2 and Go 1.6
final. I don't want to make a big deal, but thought I should mention it.

The Go Release Cycle wiki page states: "A release should not contain
significant changes since the last release candidate."

The change in question is this one "net/http: be more conservative about
enabling http2 on Transports":
https://go.googlesource.com/go/+/79d9f48c73124eb21db99efa4b97cee044f52700

Which caused a few users of my library to report the following issue:
https://github.com/RobotsAndPencils/buford/issues/26

So I guess my question is, what qualifies as a "significant" change?

I do think this is a fairly isolated case. I'm using the http/2 client
rather than server, and I require a certificate other than the default
root-ca. If my library and a handful of people are the only ones who
noticed, maybe the change isn't that significant.

In the end, I patched it up, and everything is fine. Life goes on, and I'm
happy that Go 1.6 is out for the release party celebration instead of
delayed by an rc3.

For future releases, I'm happy to run off tip and add tip to CI.

Cheers,
Nathan.

On Thursday, 28 January 2016 08:24:06 UTC-7, rsc wrote:

Go 1.7 will be a couple weeks shorter than usual, because Go 1.6 ran long.
This is now a pattern for our release cycles, one we need to break. For Go
1.3, Go 1.4, Go 1.5, and Go 1.6, the first real beta was three, four, five,
and six weeks late respectively. We make up for it by rushing the rest of
the freeze, cutting from the time scheduled for polish, production testing,
and planning of the next release. Rushing the end is no fun and also
produces bad software, or at least software that isn't as good as we would
like.

This mail is about the release cycle and what we can do to make it work
better, both for delivering releases on time without rushing and for making
contributing to the project a better experience.

We've known about the delays for a while. At the beginning of the last
cycle I wrote:

We are also going to try to make sure we stay focused on issues and
pending CLs throughout the Go 1.6 cycle. Too many of both were left until
the freeze during Go 1.5. The new Go1.6Early milestone in GitHub is meant
to help, and I intend to set up a single automated weekly mail to
golang-dev reminding us what's pending, summarizing CLs, issues, and
proposals.

We had trouble following through on that. One reason is that there weren't
enough of us on the Go team at Google handling incoming code reviews and
bug reports, including me being absent for a large chunk of the time. We
are going to try to make keeping up with code reviews and bugs more of a
focus this cycle, and we're going to be more realistic about marking issues
Unplanned if there's simply higher priority work to do.

Although I did experiment with a weekly automated mail to golang-dev, it
didn't really help because there were too many pending code reviews and
issues, so the mail was too large to be useful. I'd like to get the pending
CLs and issues cut to something reasonable early in the cycle, and then I
intend to try sending the weekly mails again to help maintain a reasonable
level. We'll see.

I think another reason for the schedule slips in the freeze is that we've
never clearly written down what the freeze means and what the milestones
inside the freeze are. It was clear to me even in December that the release
would be a few weeks late at the very least, by comparing where we were to
where we needed to be. I realized that we've never written down the
milestones that we have during the freeze that let me see that, so I
rewrote our Go Release Cycle wiki page <https://golang.org/s/release> to
have significantly more detail about targets during the cycle. The most
important part is that we can't just leave all bug triage and fixing to the
freeze. It has to be an ongoing process during the cycle. I want to break
explicitly the growing consensus that "fixing bugs is for the freeze."

That's what I see from my side of the release cycle, but I also want to
make sure the overall development process is working well for all of you,
our contributors. That's very important both to me and to the success of
the project.

I'd like to hear more, though, about what you think we should be doing
differently, what bothers you, and what would help you contribute more
effectively.

If you have any suggestions about any of those topics or about how to make
the release cycle run more smoothly, or if you have comments on the release
cycle wiki page (really a first draft), please reply here on this thread.
(If for some reason you'd prefer not to reply publicly, it's okay to write
directly to me instead.)

Thanks very much.
Russ
--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

Discussion Posts

Previous

Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 5 of 7 | next ›
Discussion Overview
groupgolang-dev @
categoriesgo
postedJan 28, '16 at 3:24p
activeFeb 19, '16 at 8:05p
posts7
users5
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase