[golang-dev] Go release cycle and contributing

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

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