IMHO the historical reason people were fixing bugs mostly during the freeze
the fact the the freeze period is so long. The tree, basically, is frozen
half the time.

You can write "the freeze is for polishing", but the fact the the code is
frozen for 3
of the 6 months of the development cycle says, loud and clear, "we're going
to use
those 3 months to fix stuff". People are not going to waste time fixing
bugs during the
development phase because they know that once the tree is frozen you can't
merge new code or even fix bugs that are in the Unplanned milestone.

In the new cycle wiki page you have made clear that there's actually 1
single month
(the first one) dedicated to fix bugs during the freeze, and that will
probably help
dispel the belief that "yeah, we have 3 whole months to fix stuff", but I'm
not convinced
it'll be enough. The tree will be frozen half the time, exactly as before,
and I'm not
sure the changes in the doc will actually encourage people to look at bugs
during the
3 first months of the cycle. People will keep prioritizing work that can
only be done
when the tree is open, because it makes sense to do so.

p.s. there's a small typo in the github wiki page: "explictly"

Il giorno giovedì 28 gennaio 2016 16:24:06 UTC+1, rsc ha scritto:
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 [email protected].
For more options, visit https://groups.google.com/d/optout.

Search Discussions

Discussion Posts


Follow ups

Related Discussions

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



site design / logo © 2023 Grokbase