profile
viewpoint

Ask questionsadd "Backlog" milestone

There are too many open issues in the Go1.14 milestone (and historically). This causes milestones to be considerably less useful as a planning mechanism.

Moving issues that likely won't be fixed in 1.14 to the Unplanned milestone (defined as "might be fixed at some point, but nobody is planning to do it.") isn't sufficient as it will appear as if we are deprioritizing the issue to a bucket that we don't pay attention to (plus we do actually plan to fix the issue, just not in the current milestone).

Kicking all issues to the following milestone (1.15 in this case) makes it difficult to plan that milestone due to the same problems stated above.

I propose we add a new milestone Backlog to mean "issues that really should get fixed, but will not happen in this release".

Taking the current cycle as an example, this would result in the following priority levels:

  • Soon label: "This should be fixed very soon" (used rarely)
  • Go1.14 milestone: "This really should get done in this release"
  • Backlog: "Someone has plans to work on this, but it won't happen in this release"
  • Unplanned: "No one has plans to work on this"

If approved, the following things would need to happen (will update this list accordingly):

  • [x] Create the milestone
  • [x] Update https://golang.org/wiki/HandlingIssues#milestones
golang/go

Answer questions neelance

@bcmills Did I phrase it badly? I was not trying to say anything about fixing it early. I'm just saying that with every release that passes with an issue in the backlog not being fixed, the probability of "probably eventually" becomes lower. If it wasn't important enough for several releases, it is unlikely to be important enough to be included in future releases. So the issue shifts from "probably eventually" to "probably never". I'm just suggesting that a default expiry of issues from backlog to unplanned would mitigate the concern that the backlog can grow without bounds (which may or may not be a problem).

useful!

Related questions

cmd/link: segmentation fault during mach-o linking hot 4
cmd/go: cannot find module providing package error stops `go get` processing hot 2
cmd/go: needs a better error than "missing dot in first path element" when GOROOT is set incorrectly hot 2
x/xerrors: fails to compile on tip hot 1
vendor/golang.org/x/xerrors/adaptor_go1_13.go:16:14: undefined: errors.Frame ... hot 1
cmd/go: `go clean <package>` downloads modules hot 1
cmd/cgo error: runtime: unknown pc 0x7fff5c805b86 hot 1
runtime: crash with "invalid pc-encoded table" hot 1
cmd/vet: potential false positive in the "suspect or" check hot 1
cmd/link: showing many ld warnings of "building for macOS, but linking in object file" hot 1
runtime: go program crach, it seems fall into infinite loop hot 1
cmd/go: major version without preceding tag must be v0, not v1 - breaks build of github.com/go-check hot 1
runtime: macOS Sierra builders spinning hot 1
cmd/go: Problem using go modules hot 1
cmd/go: "unrecognized import path" for local packages after updating to go1.13 hot 1
Github User Rank List