x/build/cmd/gopherbot: released things get marked Unreleased

[rsc]

Any issue in an x/ package that is vendored into the release should not be milestoned Unreleased by Gopherbot.

Issue #32441 was left alone for a long time in part because it was in the Unreleased milestone.
And it appears to have ended up in the Unreleased milestone because Gopherbot put it there.
And Gopherbot appears to have put it there because the title said "x/net/http".
My assumption is that Gopherbot has a rule that issues with titles beginning with "x/" (or maybe a specific list of repos) get placed in the Unreleased milestone.
This rule is too aggressive: x/net/http is included in releases, so it is wrong to mark its issues Unreleased.

In addition to fixing Gopherbot, we may want to investigate potentially mis-milestoned issues.
A quick scan turns up the following issues in release-vendored packages which are in the Unreleased milestone but perhaps should not be:

#24870 x/net/dns/dnsmessage: cannot parse mDNS SRV records
#24288 x/net/dns: invalid assumptions about domain names and character strings

#38064 x/net/http2/h2c: POST from Java 11 client code causing error in h2cUpgrade
#37089 x/net/http2/h2c: http BaseContext/ConnContext methods are not used
#26682 x/net/http2/h2c: support closure of all connections and graceful shutdown
#29187 x/net/http2/hpack: Regression in dynamic table size updates
#20574 x/net/http2/hpack: Write customer-header into HPACK byName Map rather than byNameValue
#30407 x/net/http2: Expose isBadCipher
#13434 x/net/http2: TestServer_RejectsLargeFrames fails with "An existing connection was forcibly closed by the remote host" on windows
#18273 x/net/http2: TestTransportFlowControl takes 31 seconds on OpenBSD
#25793 x/net/http2: Transport ignores net/http.Transport.Proxy once connected
#18341 x/net/http2: Transport should handle 421
#17265 x/net/http2: access to maxConcurrentStreams
#17776 x/net/http2: add a MarkComplete method to ClientConnPool
#35860 x/net/http2: cannot create 'MaxConcurrentStreams' streams with a single ClientConn
#37505 x/net/http2: data race in onSameConn test helper
#15998 x/net/http2: data race on DebugGoroutines
#16029 x/net/http2: deal with half-closed remote in Transport, flaky TestTransportResPattern_c0h1d0t0, TestTransportResPattern_c1h2d0t0
#17775 x/net/http2: expose CloseIfIdle and ClientConnPoolIdleCloser
#32388 x/net/http2: pool deadlock
#16581 x/net/http2: rename and export Transport's t1 field
#31170 x/net/http2: sendWindowUpdate may send invalid window size increment
#25117 x/net/http2: steady performance degeneration seen with HTTP/2 over recent releases
#15592 x/net/http2: toggle HPACK dynamic table indexing for header
#29125 x/net/http: PROTOCOL_ERROR with HTTP2
#19603 x/net/idna: support label separators other than ASCII dot

#33508 x/sys/cpu: add support for ARM
#30239 x/sys/cpu: report core information and speed
#33963 x/sys/cpu: respect CPU feature overrides specified in GODEBUG

#9055 x/text/unicode/norm: LastBoundary is inconsistent

[andybons]

Yep. The logic for this is https://github.com/golang/build/blob/master/cmd/gopherbot/gopherbot.go#L835

Edit: we explicitly leave out vendored subrepos: https://github.com/golang/build/blob/master/cmd/gopherbot/gopherbot.go#L851 but the above issues don’t meet the initial requirements to be excluded, so they can bucketed in “Unreleased” then never moved out.

@dmitshur @cagedmantis @toothrot

[dmitshur]

Issue #32441 was unfortunate in that it both had a "x/" prefix, yet it didn't match a real package "x/net/http2" that exists and is vendored.

One way to make that task of adding "Unreleased" milestone less likely to be applied on the wrong issues, without also causing more work for humans doing the issue triage, is if we start (automatically) tracking directories that exist in golang.org/x repos and packages that are vendored in the past 2 releases. (For an example of this being done, see the source code behind the https://goissues.org/-/packages page.)

Then it becomes possible to make it only add the "Unreleased" milestone if a the issue prefix matches a real package that exists, and that package isn't vendored.

This would prevent the milestone from being incorrectly added when an issue mistitled like "x/net/http" (instead of "net/http"). But it wouldn't help if it's mistitled like "x/image/draw" (instead of "image/draw") because golang.org/x/image/draw is a package that exists.

[dmitshur]

I have long term plans to work on this, but it won't happen in the Go 1.17 timeline, so moving this issue to Unreleased milestone which is appropriate.