Backporting contributions / contributing backports

Is there a workflow for contributing backports of “backport-nominated” fixes?

1 Like

My “workflow” was to create a backport PR Backport fix #19536 of Scala.js Dynamic by OndrejSpanel · Pull Request #19979 · scala/scala3 · GitHub and then pester someone (sjrd in this case) until it is accepted.

There is project at lampepfl - Scala 3.3 LTS backports · GitHub which looks very smart, but I do not think it is really used, at least this particular fix is still in the “Needs Assessment” column, is spite of being already merged into the release-3.3.4 branch, thus belonging to “Backport Done”.

Thanks, that is one of the PRs I looked at. But what are release branches as opposed to lts-3.3?

The branch environment is much simpler on scala/scala, where there is no 2.14.x. Also, there is a policy there of merging forward.

Is any backport-nominated PR a “good first issue”? The change is presumptively “safe and effective”, which is a simplification, but maybe there are other considerations, such as priority or bandwidth of maintainers.

(Backports can wait indefinitely, since they are less likely to suffer merge conflicts.)

Now who to pester to make the whole nomination / backport process more transparent and documented? Take e.g. Fix Closure span assignment in makeClosure by Florian3k · Pull Request #15841 · scala/scala3 · GitHub - from my point of view this is a must for LTS. Debugging any non-trivial code without this fix is extremely frustrating.