If the bug can be categorized into a particular component, you can freeze
that component immediately until the bug is fixed. That will make bugs
highest priority explicitly. I believe many companies do it the way as well.


An interesting observation, as an outsider, is the different opensource
approaches conducted by the Go project and Apple's Swift project.

The Go project uses the issue tracker provided by Github, but does not use
the pull request.
The Swift project does the opposite. They host their own JIRA bug tracker
but embrace the Github's built-in pull request.

This arguably creates different and biased economic incentives/barriers for
the two projects.

For Go contributors, opening an issue about bugs, feature requests, or some
random proposals is very cheap, which unfortunately also requires manpower
to examine, verify and response. As we all know, there is no shortage of
ideas and bug reports. However, contributing code to the Go project has a
much higher barrier, not that it's technically difficult but the lack of
incentives to learn and set up an exotic workflow and environment that are
not very useful in other places.

But for Swift contributors, raising a bug or proposal is more cumbersome
than sending a patch. I remember they got dozens of typos fixed and minor
cleanups by random strangers just in the first week after putting the code
I sometimes half-jokingly think that the Swift guys have learned that from
the Go project.

That being said, the Go toolchain is very simple and friendly to dive in,
in terms of codebase. It has no complicated build system (no autotools,
CMake, or yet-another build tool messes that pull a shitload of other
dependencies), very fast development iteration, close-to-zero dependency

In summary, I suggest more intimate integration with Github (that is,
properly utilizing its functionalities like pull request) and leveraging
resources like drone.io and coveralls.io for QA like other large Go
projects do, instead of just heavily relying on code review.
On Thursday, January 28, 2016 at 11:24:06 PM UTC+8, 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

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

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

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.
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


Follow ups

Related Discussions

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



site design / logo © 2021 Grokbase