Request to cut a patch to fix broken batch changes details page
Created by: eseliger
@sourcegraph/release-guild I am requesting the following commits be included in a patch release. They are already merged into main
:
- https://github.com/sourcegraph/sourcegraph/commit/f21dd6170cb92eafd35088f670e83cd609ff0147 (PR: https://github.com/sourcegraph/sourcegraph/pull/40857)
The intent of the questions below is to ensure we keep Sourcegraph high quality and only create patch releases based on a strict criteria. If you can answer yes to many or most of these questions, we will be happy to create the patch release.
I have read when and why we perform patch releases and answer the questions as follows:
Are users/customers actively asking us for these changes and cannot wait until the next full release?
Let me quote CE: The customer who reported this is actively blocked on an important task and they would like this issue solved sooner rather than later. Customer issue: https://github.com/sourcegraph/customer/issues/1262
Are the changes extremely minimal, well-tested, and low risk such that not testing as we do in a full release is OK?
Yes, it adds a single flag to a component that I verified against the offending PR where it was dropped accidentally. I verified the behavior the customer is seeing is no longer happening and had 3 people look at it.
Is there some functionality completely broken that warrants redacting the prior release of Sourcegraph and advising users wait for the patch release?
When more than 1 lists on the batch change page contain data, those will race to update the URL since both are still in DOM, although hidden. This can cause the page to freeze, but I don't think it's a major critical breakage that would warrant redacting the release.
This will interrupt our regular planned work and release cycle, taking one full working day of our time, and will take up all of our site admin's valuable time by asking them to upgrade or producing noise for them if they don't need to upgrade.
Do you believe the changes are important enough to warrant this?
As we weren't able to find a reasonable workaround and the customer is blocked, my opinion is yes.
Patch releases are a signal we can do something better to improve the quality of Sourcegraph. Have you already scheduled a call (or created a google doc) to perform a retrospective and identify ways we can improve?
No, but we agreed on additional integration testing in the PR.
For the Release Captain - after reviewing this request:
-
Comment on this issue with a decision regarding the request. -
If you are a first-time Release Captain, please review the high-level overview of the patch release process. -
If approved, add it to a patch release: - If there is already an upcoming patch release, add the listed commits alongside a link to this issue
- If there is no upcoming patch release, create a new one:
-
Update dev/release/release-config.jsonc
and open a PR tomain
to update it-
Change upcomingRelease
to the current patch release -
Change previousRelease
to the previous patch release version -
Change releaseDate
to the current date (time is optional) along withoneWorkingDayAfterRelease
andthreeWorkingDaysBeforeRelease
-
Change captainSlackUsername
andcaptainGitHubUsername
to the patch captain's
-
-
Run yarn release tracking:issues
onmain
-
Add the listed commits alongside a link to this issue to the generated release tracking issue
-
-
Comment and close this issue once the relevant commit(s) have been cherry-picked into the release branch.