Runtime: Incorrect branch distance calculation present in .NET core 3.0+

[IntelOrca]

Issue dotnet/runtime#24818 is still present in .NET core 3.0 onwards as the fix dotnet/corefx#28493 was not merged into the 3.0 source stream.

[jkotas]

cc @tmat

[tmat]

@mmitche @markwilkie Was release/2.1 not auto-merged to master and release/3.x?

[mmitche]

There is no auto-merge from release/2,x -> release/3 for the core* repos. I believe this was intentional given the large differences in those products.

Please port.

[jkotas]

The default workflow for runtime repos is:

1. Submit the fix to master first
2. Cherry-pick the fix into release branches as necessary (this typically needs ship room approvals, etc.)

[tmat]

@mmitche @jkotas I'd expect changes release/2.1 to flow to master to avoid issues like this one. That's certainly standard flow in many other repos.

[tmat]

Should I now port it to release/3.1 and also to master, or does release/3.1 flow to master?

[jkotas]

release/3.1 does not flow to master. Get it to master first. Once it is in master, submit a backport PR and follow the servicing process for this. (I would port it to 3.1 only. 3.0 is a very short-lived release.)

[tmat]

What's the rationale behind not flowing 3.1 to master? This process is just adding unnecessary work and is error prone.

[jkotas]

Due to high churn in coreclr/corefx, flowing 3.1 to master would add even more unnecessary work and it would be even more error prone.

[jkotas]

E.g. you can try to merge release/3.1 to master locally to see the giant amount of merge conflicts.

[tmat]

Odd, Roslyn has been doing this for years and we've had no issues.

[jkotas]

That's certainly standard flow in many other repos.

It is not the industry standard. The industry standard is to submit to master and back-port as necessary. There is no automatic flow from servicing to master in any of the major open source projects that I know about: Linux kernel, LLVM, ... .

[danmosemsft]

Due to high churn in coreclr/corefx, flowing 3.1 to master would add even more unnecessary work and it would be even more error prone.

On top of above reasons, another reason is that often a fix is already in master when we decide to port it. In those cases inevitably the backport is second and it's nice to have a consistent flow.

[tmat]

@danmosemsft So in that case, the flow would be a no-op.

[tmat]

I don't actually care that much about where the fix goes first. The bigger issue is that our repos are not consistent and I can't track each repo's flow in my head while contributing to dozens of repos.

[jkotas]

The bigger issue is that our repos are not consistent

So get the repos that are not following the industry standard to change.

[tmat]

@jaredpar @jasonmalinowski

[tmat]

So if we change the flow, how do we prevent issues like this - when a change is merged to servicing branch without being merged to master?

[stephentoub]

when a change is merged to servicing branch without being merged to master?

If the flow is merge first to master and then port to servicing as appropriate, when would that ever happen?

[tmat]

If the flow is merge first to master and then port to servicing as appropriat

It happened because no one was apparently enforcing that. https://github.com/dotnet/corefx/pull/28493 was not merged to master.

[stephentoub]

Are you asking then for tooling to be put in place?

Mistakes can be made regardless of the flow direction. With either direction tooling can help.

[tmat]

Are you asking then for tooling to be put in place?

Ideally, yes.

Mistakes can be made regardless of the flow direction

Sure, the mistake happened because I expected the flow from servicing to master to happen automatically because that's what other repos I work with do.

[mmitche]

Mistakes can be made regardless of the flow direction. With either direction tooling can help.

Yep

Sure, the mistake happened because I expected the flow from servicing to master to happen automatically because that's what other repos I work with do.

This flow is really tough for any repos that are not leaves in the dependency graph. Inter-branch merges are really painful when the version files are always getting edited. I'm beginning to think that this automation provides more pain and possibility of mistakes than value.

I'd be more of a fan of putting in automation which would keep track of the product relatated-ness of various branches and repos (e.g. release/2.1 is related to release/2.2) and identify cases where fixes in one branch are not merged into oither branches. It could be more selective, and allow the user to either dismiss the warning (fix not applicable to branch) or cherry-pick the fix along.

[jasonmalinowski]

With either direction tooling can help.

We've always been strict with Roslyn to ensure the old branches are merged forward, precisely to make sure that even if a mistake happens we did get stuff being pulled forward. It also means that it's often easier to figure out which release a fix shipped in: if you have the commit in master you don't have to find the "other commit" that did the backport if the change was originally done in the other branch. Of course, this doesn't always work so you might have to do a search no matter what, but it means a "does release X contain fix Y" is potentially much faster to answer "yes" to.

I will also express some concern about "industry standard" as a phrase being tossed around here -- the Visual Studio repo for example does not require "backport from master" and flows changes forward, and I can think of plenty of repos do this in the dotnet org here. And those repos have good reasons for doing the flow they are doing. I'm not saying we shouldn't unify on a single model, but "they should just change" is far more complicated and and dismissive of needs they have.

[jkotas]

the Visual Studio repo for example does not require "backport from master" and flows changes forward

Visual Studio is closed source desktop app. I have in mind the standard of large open source infrastructure projects (OSes, compilers, core libraries, etc.). Are you aware of any non-.NET projects in this category that encourage submitting patches to servicing first and then automatically flow them to master?

Related: https://www.bing.com/search?q=upstream+first+policy

[danmosemsft]

This should be closed as the fix is everywhere now.