You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@agnivade If we decided we are not backporting something, yes we should close the issue. But reasons to push to the next release include: the fix is not ready, the cherry-pick is not finished, and a decision wasn't made. Then the issue is useful to keep track of it.
There is a gap in the process in that we did not have a process to go through the open issues and make decisions for the ones that are ready. We'll address that soon.
Activity
agnivade commentedon Oct 2, 2018
@FiloSottile - Related to this, there are also backport issues which keep getting pushed back to the next minor release milestone.
If we aren't going to backport a fix, shouldn't we just close the issue ? Is there a reason, a fix should not be in 1.11.1, but in 1.11.2 ?
FiloSottile commentedon Oct 2, 2018
@agnivade If we decided we are not backporting something, yes we should close the issue. But reasons to push to the next release include: the fix is not ready, the cherry-pick is not finished, and a decision wasn't made. Then the issue is useful to keep track of it.
There is a gap in the process in that we did not have a process to go through the open issues and make decisions for the ones that are ready. We'll address that soon.
dmitshur commentedon Oct 7, 2018
@FiloSottile I just checked https://github.com/golang/go/milestones?state=closed, and I think the original issue is resolved by now. If there's nothing more to do here, we can close this.
(There was one open issue in the closed Go1.11 milestone, because it got reopened recently. I fixed it by moving it to Go1.12 milestone.)
FiloSottile commentedon Mar 8, 2019
On second thought, this is not worth automating.