It's kinda mind-boggling to me that after making a change to the build definition, there was no way to try it out and see if it works, other than committing the change and waiting until the next day to see if it broke the build.

My question is: how was anyone expected to make changes to the build definition if this was the only way? Wait a day to find out if it worked, and break the build for everyone if not?

▲

rincebrain 2 days ago | parent | next [-]

My understanding from other anecdotes about Microsoft is that a lot of their internal tooling, for a very long time, remained the kind of hideous nightmare of interwoven dependencies and build times measured in hours that we try to avoid in most modern setups.

I would speculate that in most parts of the company that haven't been left to rot that's hopefully no longer true, but I have no direct anecdotes about that, I just would have assumed it to be a target for someone looking for their iteration cycles to be saner at some point, and once one group managed it, etc.

	▲	sterlind 2 days ago \| parent [-]
		never was part of Windows, but from my limited interactions with it the old build system was a chimera of Perl scripts, passes, Makefile-like things and other tooling. build labs would run and jobs would take hours. it underwent a Herculean effort to modernize it, converging on the actual VS build system and from sd to git. it seemed much healthier last I looked.

▲

mtlynch 2 days ago | parent | prev [-]

>how was anyone expected to make changes to the build definition if this was the only way? Wait a day to find out if it worked, and break the build for everyone if not?

You could build a subcomponent of Windows source locally, and 99% of the time, you knew which subparts of the source tree to build locally to have confidence that you wouldn't break the build.

The problem was that if I was doing something exotic nobody has tried before, I'm suddenly in the 1% case where I no longer have confidence that building locally will eliminate all issues.