Hongxiang Jiang

cc @findleyr @adonovan This remind me of another feature request to re-arranging code actions returned from gopls. Maybe some grammar similar to the glob expression in `DirectoryFilters` where users can...

In the next change, we will add a step to create a branch for a minor version (X.Y.0) release. In my local run, the release flow failed because of permission...

In the next change, we will add a step to change the `codereview.cfg` under the root dir of `x/tools` repo, and create a CL based on the change. The flow...

In the next change, we will add a step to update the `x/tools` dependency in the `gopls` sub module, and create a CL based on the change. The way of...

In the next change, we will add a step to verify we can successfully install gopls from the head of the branch using the `go install`golang.org/x/tools/gopls@{BRANCH_NAME}`.  Update: The gopls...

In the next change, we will add a step to tag the pre-release for a given release. In my local run, I tried to release a new gopls version 0.16.2....

Next change, the release automation will find the release milestone and create a release tracking issue. All the CL created for this release should reference this issue (part of the...

Next change, the release automation will re-run a verification after tag the pre-release version. So the workflow will verify the gopls installation twice. From the high level, the flow looks...

Next change, we will rename the current flow to pre-release flow. The pre-release flow is responsible for preparing a pre-release candidate but the release flow is responsible for release a...

Next change: as an improvement, we will replace current approach updating the x/tools dependency using `branch` with using `commit`. This is to avoid any possibility where the module proxy provide...