Thanks @NotMyFault

Why was this PR needed? As far as I can tell, it contained no justification and everything that we cared about from an end-user perspective had been backported already (without the nuget.exe bug). As far as I can tell this PR only had the effect of introducing the nuget.exe bug.

Why was this PR needed?

It's part of the LTS release checklist. The LTS part expects that the stable branch is up-to-date with changes from the master branch.

Well sure but this kind of blind merging is precisely the type of thing that Wadeck was objecting to in another thread. There needs to be a justification for each backport.

Well sure but this kind of blind merging is precisely the type of thing that Wadeck was objecting to in another thread. There needs to be a justification for each backport.

this is not a backport as such, we freeze the branch at the start of each new LTS line (can be frozen earlier if say weekly has moved on with a breaking change we don't want to pull).
After the .1 release then yes changes should be backported on an as needed basis.

we freeze the branch at the start of each new LTS line

Then why even create the branch earlier? Just create it at the time that you are freezing it. But this doesn't make sense to me, since the entire point of a stable branch is to freeze it before the release to create a window of time during which stabilization can occur.

Then why even create the branch earlier?

A legitimate question. The packaging branch isn't needed until you plan to trigger the LTS job, is it?
The branch is created if you initiate a new LTS line and use the init-lts-line script.
If this happens 3 or 4 weeks before the LTS release takes place, master and stable branches easily diverge.

Then why even create the branch earlier?

Might be a side effect from making the LTS decision earlier before the previous LTS line is even finished. Previously, the baseline decision (and start of backporting) was the same week as .3 release, which would be a natural time to start creating branches.

If this happens 3 or 4 weeks before the LTS release takes place, master and stable branches easily diverge.

Why do we need to pick up packaging changes in weeklies after the baseline? Selectively for infra reasons makes sense, as well as regular bugfix backports like we do in core, but wholesale everything?

Why do we need to pick up packaging changes in weeklies after the baseline? Selectively for infra reasons makes sense, as well as regular bugfix backports like we do in core, but wholesale everything?

Exactly, that is my point as well regarding stabilization. The primary purpose of branching x number of days/weeks prior to a release is to avoid picking up potentially buggy commits on the stable branch, i.e. to create a stabilization period. Syncing indiscriminately during that time exposes the stable branch to new bugs/regressions, which defeats the point.