Requesting backup!

[som-snytt]

... as they say on police procedurals. What is the channel to request a commit on main get backported to 3.7.1 that is at RC-1?

Ondřej asked about a fix for linting that missed the boat.

@WojciechMazur may know if there is a process.

[tgodzik]

The process is that people should let us know in the PR and we might decide to backport it. Did we miss one and didn't respond?

[tgodzik]

Nvm, I see it.

[som-snytt]

Thanks, I don't want to make extra work or noise, and the release process has been amazing, so normally I'd just trust it.

[WojciechMazur]

Scala Next

For Scala Next RC backports it's best to add label backport:nominated and ping release officer, currently me @WojciechMazur

In the scala/scala3 repository we're using a dedicated labels (backport:*) to mark PRs that should be backported from main to latest release candidate version:

• backport:nominated - assigned to PR merged on main that should be backported to latest release candidate
• backport:accepted - assigned to previously nominated PR that was accepted by the Release Officer
• backport:done - assigned when accepted backport was merged to the release branch

Scala LTS

For Scala LTS we have a dedicated workflow
Every PR merged to main branch is automatically being added to the LTS backports project with theNeeds Assement status. The role of LTS release officer is to decide which PRs can and should be backported to the LTS series. Officer needs to manually check content of each PR and approve it (by moving PR to Backporting In Progress) or reject by setting state to Backport Rejected. The decision on should the PR be backported should follow the dedicated decision graph
Later we use dedicated scripts to perform backports/cherry-picks and procedure of testing using Scala 3 CI and Open Community Build. If no new regressions are found, the backports are merged into https://github.com/scala/scala3-lts from which we would cutoff the next LTS patch release