[mdriley]

Er, a few problems with the reasoning here:

1. Windows developers did not build large parts of the product on any regular basis. Windows took ~18 hours to build on incredibly powerful build lab hardware -- as soon as it took longer, it was time to buy a new build lab. Incremental rebuilds were notoriously flaky, at least in the days before https://github.com/microsoft/BuildXL. The most common dev loop that I saw was to install a recent dogfood build (so APIs and binary interfaces were reasonably recent) and then repeatedly rebuild and clobber binaries on that install.

2. The only real build-configuration options for timebuild were architecture and compile mode (dbg, chk, fre, opt). There wasn't an option to build or not build parts of the tree.

3. raymondc's reference to "kernel-colored glasses" is about viewing things from the kernel side of API guarantees. This is more an applied lesson in Conway's Law.

[derefr]

Re: the second point, I wasn't hypothesizing passing a runtime option to timebuild, but rather running a build against a local "root enlistment directory" that has the Base and Windows depots synced, but not necessarily all the depots for the other components.

I suppose this wouldn't have resulted in an installable release, though. (At least on its own. I guess the populatefromvbl.pl script described in the memo is there to bodge a partial clean build of individual components, together with "the rest of Windows" from some parent release, to form a test build?)