FAQ
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

  • Alb at Feb 3, 2016 at 5:27 pm
    IMHO the historical reason people were fixing bugs mostly during the freeze
    is
    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
    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.
  • Mura at Feb 5, 2016 at 4:11 am
    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
    online.
    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
    etc..

    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
    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.
  • Andrew Gerrand at Feb 5, 2016 at 4:28 am
    Hi, thanks for the thoughtful suggestions.
    On 5 February 2016 at 14:40, mura wrote:

    In summary, I suggest more intimate integration with Github (that is,
    properly utilizing its functionalities like pull request)
    We would not switch to using GitHub's Pull Requests any time. The Go
    contributors spend a huge amount of time reviewing code, and the PRs
    workflow is woefully inadequate compared to Gerrit. We're not the only ones
    who think so, and GitHub are aware of the issues.

    FWIW, I think our priorities are set correctly. It should be much easier to
    file an issue than to send a change. Issues should be filed by literally
    anyone who encounters an issue, while changes to the code base should be
    carefully prepared by people who are invested in the project.

    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.
    We do have a comprehensive continuous build system
    <http://build.golang.org/> that is integrated with our code review process.

    Cheers,
    Andrew

    --
    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.
  • Nathan Youngman at Feb 19, 2016 at 3:21 am
    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.
  • Russ Cox at Feb 19, 2016 at 7:30 pm
    We broke the rule, and we shouldn't have. Our bad. If the CL had really
    just been disabling a corner case, I think that would not be a significant
    change. But both Brad and I missed that the CL did more.

    The bar is *slightly* lower for new functionality than functionality
    carried from a previous release. Although we released with less HTTP/2 than
    we should have, it was still not a regression from Go 1.5. We wouldn't have
    even considered the change if HTTP/2 had been in 1.5.

    Russ

    On Thu, Feb 18, 2016 at 10:21 PM, Nathan Youngman wrote:

    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.
    --
    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.
  • Nathan Youngman at Feb 19, 2016 at 8:05 pm
    Yah, today I saw that the CL had a larger impact than I originally thought.
    Glad to see the fix is already there for Go 1.6.1 along with a new test.
    https://github.com/golang/go/issues/14391

    Usually the x.y.1 releases don't come out right away. Do you expect 1.6.1
    will come out fairly soon to resolve out-of-the-box http2 support?

    Either way, I think I need to pull in x/net/http2 for what I'm doing, so
    I'm certainly not in any rush.

    Nathan.
    On 19 February 2016 at 12:30, Russ Cox wrote:

    We broke the rule, and we shouldn't have. Our bad. If the CL had really
    just been disabling a corner case, I think that would not be a significant
    change. But both Brad and I missed that the CL did more.

    The bar is *slightly* lower for new functionality than functionality
    carried from a previous release. Although we released with less HTTP/2 than
    we should have, it was still not a regression from Go 1.5. We wouldn't have
    even considered the change if HTTP/2 had been in 1.5.

    Russ

    On Thu, Feb 18, 2016 at 10:21 PM, Nathan Youngman wrote:

    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.

    --
    Nathan Youngman
    Email: hello@nathany.com
    Web: https://nathany.com

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

Related Discussions

Discussion Navigation
viewthread | post
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