Runtime: Rename RuntimeOS to BuildOS

[ViktorHofer]

We agreed on using the terms BuildOS for the build machine's OS and TargetOS for the target platform's OS. We should rename the existing RuntimeOS property to reflect that.

cc @ericstj @jkotas

[stephentoub]

It's great that we're improving the build system. Every time we change something like this, though (and that's been happening a lot recently), devs need to unlearn the old thing and learn the new thing, fighting muscle memory, and usually after having build problems that they then need to figure out how to resolve. Can we put in place some guardrails, a timeline that indicates what we expect to change and when, and at what date we expect no further such changes for the foreseeable future? Again, I'm not objecting to the changes / improving things, as that's important, but the incremental trickle is starting to wear me down ;-)

[ViktorHofer]

and that's been happening a lot recently

... because we consolidated three repositories into one.

need to figure out how to resolve

I understand that the last months were rough in terms of productivity because of so many moving pieces but we can't stop making progress until the consolidation is done.

I would say we are midway through but still need to tackle big rocks that will definitely cause more disruption to meet the goals defined here: https://github.com/dotnet/arcade/pull/4980.

We usually try to announce changes that disrupt the dev workflow via a pinned announcement issue and in addition to that via mail to the team. Let me know if you think we should consider other communication channels as well (ie Gitter).

when, and at what date we expect no further such changes for the foreseeable future?

We always try to batch changes together that potentially cause disruption but when working on long-term goals (e.g. dotnet test), that's not always possible.

Can we put in place some guardrails, a timeline that indicates what we expect to change and when, and at what date we expect no further such changes for the foreseeable future?

Again, I'm not objecting to the changes / improving things, as that's important, but the incremental trickle is starting to wear me down ;-)

Understandable. cc @ericstj @jaredpar @danmosemsft

[stephentoub]

because we consolidated three repositories into one.
I would say we are midway through

Yes, in December. It's now March. And many of the changes being made are orthogonal to the repo consolidation.

Again, I'm not criticizing the work or the quality of the work or even the timeline; it's a lot of change for a good end reason. It just seems like every week for the past three months there's been at least one change that causes every dev on the team (that includes the whole community contributing to the repo) to need to re-learn something about their workflow. Maybe I'm misremembering or overstating, but I'm so confused at this point. Do I use /t:rebuildandtest or /t:buildandtest or /t:test, and what does that end up doing? Do I use /p:TargetGroup or /p:TargetFramework or /p:TargetOS or /p:BuildOS or...? I can't keep it straight, and it feels like every time I think I know it, it changes, which means I'm frequently getting it wrong and then either slowing someone else down by asking them or trying to find an email or an issue or something that explains what the magic incantation is today.

My request is simply that we:
a) be thoughtful about the impact this has on folks. In particular, think about the end-to-end holistically, and try to avoid changing something only to then change it again.
b) outline all of the changes that we intend to make, and with an approximate timeline for when we intend to do so, as we'd do in general with any large feature implementation plan. Is there a checklist somewhere of all of these changes? A project board showing everything that's been done, is being done, and will be done to consider the effort complete? It's possible this all exists and I'm just not aware of it (in which case I expect others aren't, either).

Thanks for all of your efforts.

[ViktorHofer]

be thoughtful about the impact this has on folks. In particular, think about the end-to-end holistically, and try to avoid changing something only to then change it again.

👍

A project board showing everything that's been done, is being done, and will be done to consider the effort complete? It's possible this all exists and I'm just not aware of it (in which case I expect others aren't, either).

These are the words were we track the work we are planning to do:

• Infrastructure Backlog General
• Infrastructure Backlog Libraries
• Infrastructure Backlog CoreClr
• Infrastructure Backlog Installer
• Infrastructure Backlog Mono

@jaredpar and I were chatting about having something like a changelog in which we list all the recent changes. The project boards helps with that but they tend to not work well with hundreds of items. We are tracking all our planned work as GH issues. We just recently created the boards but they should already provide an overview of what changes are currently being worked on. We are in the middle of triaging down the area-Infrastructure-libraries label which currently contains >100 issues.

outline all of the changes that we intend to make, and with an approximate timeline for when we intend to do so, as we'd do in general with any large feature implementation plan

ETAs are hard because of conflicting priorities (releases, servicing) but I wouldn't be against working more agile, i.e. bi-weekly Sprints.

cc @danmosemsft @ericstj

[jkotas]

@ViktorHofer @jaredpar Here are concrete suggestions for how to make things better:

• Batch the user facing changes together: Schedule 1 week every 2 months where we flush the user facing changes and people will need to adjust the workflow. It avoids the constant trickle that is wearing everybody down. You can still do most of the work in the remaining time, but it may need a bit of glue to connect new and old way - this temporary glue can be flushed during that 1 week every 2 months.

• Good user facing names matter: Have open discussion and agree about renaming and good names of public facing names before the change is made. For example, the original plan for the build OS property was not TargetOS. The new name was arrived upon only after I happened to look at the PR and pointed out the inconsistencies. Another example is src\coreclr\build-runtime.cmd script name that does not feel quite right - see https://github.com/dotnet/runtime/issues/32991#issuecomment-596796162 .

• Make sure that things constantly improve: Avoid pushing our regressions just to promise that things will get better in future. For example, your recent change that added minutes to the build is regression, with no benefits, for 95+% of the team. This change should have been pushed out only after addressing the NuGet performance issues.

[danmosemsft]

I agree with comments above (including appreciating your continuing efforts @ViktorHofer which are undoubtedly making things better over the long run). The long term direction is good we just have to tune our tactics.

One thing that's changed of course is we have approx 3x more committers in the repo as any of the old repos had. That magnifies the impact of every change now - we have to balance continuing improvement with the huge multiplier of any impact. The staging and continuous improvement suggestions are good ones.