4 ms·
Most upstreams will generally accept responsibility for keeping code working - just having it "merged" often means then handling bug reports, testing, etc. If t
by ealexhudson 13y ago
Most upstreams will generally accept responsibility for keeping code working - just having it "merged" often means then handling bug reports, testing, etc. If the Intel people don't want to maintain specialized Ubuntu-only environments just to test the Mir codepaths, that's kind of their call.
It probably also didn't help that Canonical employees were using it as a political football to boot other GPU vendors, e.g. https://twitter.com/olliries/status/375704285083738112 https://twitter.com/olliries/status/375704285083738112
It was Canonical's decision to fork, if they have to bear the costs of the fork then so be it.
- krschultz 13y agoThe old classic argument around why Linux doesn't have a rigid internal API comes to mind (http://www.kroah.com/log/linux/stable_api_nonsense.html http://www.kroah.com/log/linux/stable_api_nonsense.html). Maybe there are commonalities between supporting Mir and Wayland that would allow Intel to create a more universal piece of software? If Canonical does the work to make the driver universal, wouldn't the whole community benefit? I'm not a big fan of letting politics get in the way of engineering, and this smells of the fact that Intel is trying to battle ARM in a proxy war, with FOSS as collateral damage.
- tvon 13y ago> Maybe there are commonalities between supporting Mir and Wayland that would allow Intel to create a more universal piece of software? This still increases cost on the part of Intel.
- sounds 13y agoXMir support in intel's driver uses a significant amount of separate code. I'm not saying intel's actions are ok, but XMir is not creating anything more universal.