All i'm saying is... they could go as far as to provide the instructions to pull the necessary prereqs from source control and build from source instead of assuming a specific vendor patched binary environment as a starting point.
Wayland upstream has done a reasonable good job of providing git based build from source instructions so you can track the head of all the moving pieces when bootstrapping up a wayland/weston entirely from source..daily if you really wanted to. And its been like this for a while. Whether or not its day-to-day usable isn't not the point. Day-to-day buildable. Day-to-day testable... in whatever environment you are in. That's the point, especially for anyone who is interested in packaging this up as a piece of tech for !Ubuntu and wants to start looking for testable regressions ahead of officially packaging this crap for a wider audience.
This has nothing to do with being day-to-day usable. This is able day-to-day testable outside of Ubuntu. If they want upstreams like KDE to take this seriously as a technology to support...and more important to think of mir as an "upstream project" team they can work with, then the mir team needs to do more they make patronizing statements and offering to have conference calls with externals and start providing vendor neutral instructions on how to work with the project sourcecode. This crap isn't hard. In fact its easier now that we have distributed source code control systems. Mir devs are getting the basics of being an "upstream" project wrong and making on-ramp documentation vendor specific assumptions baked-in. The project would benefit if someone in the team did a linux from scratch install and tried to bootstrap mir on that target...just sayin.