Arcade: Policy on which branch(es) should be targeted for Arcade servicing changes?

[dagood]

I don't see it mentioned in policy how contributors are meant to file PRs to get into servicing, especially the target branch. This can cause issues when the runtime and SDK strategies collide: https://github.com/dotnet/arcade/pull/4174#discussion_r337697836.

Maybe it fits in:
https://github.com/dotnet/arcade/blob/master/Documentation/Policy/ArcadeServicing.md ?
https://github.com/dotnet/arcade/blob/master/Documentation/Policy/AskTellMode.md ?

This could be linked in the new PR template as a reminder.

@markwilkie @mmitche

/cc @ericstj

[tmat]

Seems like another instance of the policy inconsistency discussed on https://github.com/dotnet/corefx/issues/41710.

/cc @stephentoub @jkotas

[markwilkie]

@dagood - Are you thinking something beyond "tell/ask mode" to check into a servicing branch and then expecting that to flow out to master?

cc/ @mmitche

[dagood]

I think tell/ask mode is documented fine, this is the very specific thing I think should get a policy:

expecting [the change in the servicing branch] to flow out to master [rather than submitting a PR to master first then porting to the earliest applicable servicing branch (the runtime repo approach)]

[markwilkie]

@mmitche - maybe we should bring this up in tactics.

Also, I'll add a note to the ask/tell mode policy/guidance.

[markwilkie]

Ok, I just updated https://github.com/dotnet/arcade/blob/master/Documentation/Policy/ArcadeServicing.md

[mmitche]

@mmitche - maybe we should bring this up in tactics.

Also, I'll add a note to the ask/tell mode policy/guidance.

I don't think they will have interesting opinions on it. It's really up to us. Many of the repos have different policies on this. Generally, changes are checked into master or the "less risky" servicing branch and then cherry-picked after there is some validation that things work. I'd prefer that we follow that model.

[jkotas]

Generally, changes are checked into master or the "less risky" servicing branch and then cherry-picked after there is some validation that things work.

Yes, this is a better model for core infrastructure projects. It is why the runtime is using it.

[markwilkie]

Sorry - I meant to say we should perhaps give a "service bulletin" in tactics alerting folks that their servicing commits will flow to master, unless it's an exception where the servicing fix is not the "right fix". There's confusion right now in several quarters...

Also, as you say @mmitche, fixes can (and should) be cherry picked back the other way. Again, up to the different repos.

Also, @mmitche - if you want to update the doc to be more clear, that'd be great. :)

[dagood]

How about including something in the PR template, with a link to policy doc(s)? (Reopening for this Q.)

Devs who come to this repo expecting runtime-style or SDK-style and not knowing that there even is a difference probably won't think to read the entire Q&A. Or people may simply forget after spending a long time on one side or the other.

I would also strengthen this to recommend the action to take:

By default, servicing branch updates will flow to master.

By default, servicing branch updates will flow to master. Submit your change to the earliest applicable servicing branch.

I'm also in the runtime-style camp myself, but I've been aware for quite a while that things are done differently per repo. My main concern with this issue is that we at least need to be clear. (This isn't nearly as well-known as I'd thought!)

[markwilkie]

Fair enough @dagood - this is a good point and the template idea's not a bad one.