How does Linux do it? Does anyone know of any documentation for the process they follow?
Typically this is just semantics, but it's meaningful here because you still need all of the other components (GNOME and X and PulseAudio and SystemD and so on, as concrete motivating examples) to make up the whole OS.
And unsurprisingly, you end up losing out on features that would require vertical integration. Accessibility on Linux is more or less a non-starter, the design of every application and toolkit is blindingly variable, nothing about the system can be depended on (even the standard C library!) unless your app has been intentionally built and tested with that particular version of that grab bag of components.
Windows is one thing. People know what they're getting when they use it. I don't like it much, but it certainly achieves the goal it set out to accomplish. I certainly don't lie awake in bed wondering why everyone uses it over my favorite grab bag of widgets that more or less looks like an OS.
Kidding, I know that'll never happen. (Unless Electron counts as a UI toolkit, because that's apparently where we're headed.)
The way a changeset goes from a developer's machine to the root is reasonably similar (it usually gets pulled through a number a intermediate trees, from a development tree to a sub-subsystem tree to a major subsystem tree to Linus's tree), riding the train from the bottom to the top, with an additional time constraint on it (the merge window being open).
The kernel also has a "next" tree that is a snapshot of what the kernel would look like with incoming changes merged right now, surfacing early the exact long-distance coordination issues described in the article. Plus, of course, everything is in the open, so maintainers of different subsystem can then coordinate directly on things that impact both sides, even if the required patches will if possible make their way up separately.
[0]: https://www.kernel.org/doc/html/latest/process/2.Process.htm...