@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/pull/43344
  • https://github.com/sourcegraph/sourcegraph/pull/44072 (Adds the missing changelog for the above issue)
• https://github.com/sourcegraph/sourcegraph/pull/44020
• https://github.com/sourcegraph/sourcegraph/pull/43868
  • https://github.com/sourcegraph/sourcegraph/pull/44075 (Adds the missing changelog for the above issue)

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? Yes https://github.com/sourcegraph/accounts/issues/8410

Are the changes extremely minimal, well-tested, and low risk such that not testing as we do in a full release is OK? Based on what is contained in the commit above, the changes seem to be minimal and low risk.

Is there some functionality completely broken that warrants redacting the prior release of Sourcegraph and advising users wait for the patch release? Yes. Search export functionality is completely broken. This feature is one that the reporting customer uses frequently and is a core part of their workflows.

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? 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

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, open and merge a PR to main 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 with oneWorkingDayAfterRelease and threeWorkingDaysBeforeRelease
      • Change captainSlackUsername and captainGitHubUsername to the patch captain's
    • Run yarn release tracking:issues on main
    • 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.